juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sblackmon <sblack...@apache.org>
Subject Re: Quick yet powerful techniques for customizing HTML serialization
Date Mon, 24 Jul 2017 15:25:27 GMT
Thanks - I moved the write-up from ‘Pages’ to ‘Blog’.  New url:

https://cwiki.apache.org/confluence/display/JUNEAU/2017/07/24/Using+Freemarker+in+Juneau+to+render+HTML+fragments+in+tables

I’ve also started this Design document to discuss ways we can make this much easier for
developers.

https://cwiki.apache.org/confluence/display/JUNEAU/Freemarker+Template+integration?flashId=1425736656

Steve
On July 24, 2017 at 9:51:10 AM, James Bognar (jamesbognar@apache.org) wrote:

Hi Steve,  

I'll take a look at this tonight.  

The blog posts can be found here...  
https://cwiki.apache.org/confluence/pages/viewrecentblogposts.action?key=JUNEAU  

On Sat, Jul 22, 2017 at 6:14 PM, sblackmon <sblackmon@apache.org> wrote:  

> I posted a write-up of what I did to make this work on cwiki.  
>  
> It’s somewhat cumbersome to do this now (although still better than 100%  
> java), but I can see a path to making it much easier, requiring just the  
> existence of an FTL file and annotations on the resource similar to  
> Widget=/$W and bpi/bpx wherever it should be enabled.  
>  
> P.S.  
>  
> It wasn’t obvious how to place this alongside the blog posts James created  
> recently, so I placed it under How-To articles for now. Feel free to move  
> it.  
>  
> Steve  
>  
> On July 17, 2017 at 2:01:06 PM, sblackmon (sblackmon@apache.org) wrote:  
>  
> I will work on a proof-of-concept class in one of my projects that  
> implements HtmlRender<Div> using a resource FTL (free marker template) file  
> provided in the constructor.  
> On July 17, 2017 at 10:23:45 AM, James Bognar (jamesbognar@apache.org)  
> wrote:  
>  
> I'm on vacation this week so my replies may be scarce.  
>  
> Some thoughts....  
>  
> 1) We do have the HtmlRender class that allows POJOs to be serialized as  
> custom HTML (typically HTML5 beans). Maybe this could be extended for  
> particular frameworks?  
>  
> 2) It's definitely possible to define POJOs that get swapped to HTML5 bean  
> constructs. e.g. A MyForm bean that gets swapped with a populated Form  
> object.  
>  
>  
> On Mon, Jul 17, 2017 at 7:59 AM sblackmon <sblackmon@apache.org> wrote:  
>  
> > Just wanted to share that embedding widgets in inherited header and  
> > footer, and as menu items, is really helping to make s site I’m working  
> on  
> > look and feel like an application rather than a bunch of pages.  
> >  
> > I’m interested in render certain pojo types using non-standard (but  
> common  
> > throughout the application) HTML fragments. Obviously this can be done in  
> > pure java on a class-by-class basis, but maybe we should consider  
> framework  
> > support for something like handlebars or freemarker to address this  
> > use-case?  
> >  
> > Basically HTML serializer could support binding a specific POJO class to  
> a  
> > template resource file on the classpath, written in a standard templating  
> > language rather than plain java.  
> >  
> > Any thoughts?  
> > On July 10, 2017 at 1:47:41 PM, sblackmon (sblackmon@apache.org) wrote:  
> >  
> > Perfect. Thanks!  
> >  
> >  
> > On July 10, 2017 at 1:22:58 PM, James Bognar (jamesbognar@gmail.com)  
> > wrote:  
> >  
> > You can do that today!  
> >  
> > @RestResource(  
> > htmldoc=@HtmlDoc(  
> > widgets={  
> > MyHeader.class  
> > },  
> > header={  
> > "$W{MyHeader}"  
> > }  
> > )  
> > )  
> >  
> > Then your widget can be defined to load from resources.  
> >  
> > public class MyHeader extends Widget {  
> > @Override  
> > public String getScript(RestRequest req) throws Exception {  
> > return loadScript("MyHeader.js");  
> > }  
> > @Override  
> > public String getStyle(RestRequest req) throws Exception {  
> > return loadStyle("MyHeader.css");  
> > }  
> > @Override  
> > public String getHtml(RestRequest req) throws Exception {  
> > return loadHtml("MyHeader.html");  
> > }  
> > }  
> >  
> > The loadX() methods strips off comments (e.g. apache license headers)  
> from  
> > the files for you.  
> >  
> > You can embed any of the various other variables inside the files as well  
> > (e.g. $L{}, $R{}, etc....) since the $W variables are recursively  
> resolved  
> > (just like any other variable).  
> >  
> >  
> > On Mon, Jul 10, 2017 at 1:49 PM, sblackmon <sblackmon@apache.org> wrote: 

> >  
> > > +1 for more flexibility in the header region.  
> > >  
> > > Might it make sense to let developers put HTML with expressions in  
> > > separate resource files and specify the class path resource with an  
> > > annotation field, to make the fragments easier to re-use?  
> > >  
> > > Or perhaps support Widget classes as values for header, footer, aside,  
> > > etc…?  
> > >  
> > > On July 10, 2017 at 12:14:21 PM, James Bognar (jamesbognar@apache.org)  
> > > wrote:  
> > >  
> > > There's a change I'd like to make to the way the page header is  
> specified  
> > > on the HTML views.  
> > >  
> > > It's rather complicated right now. The Title and Description in the  
> > header  
> > > is added as <h1> and <h2> tags in the HtmlDocTemplateBasic class.
 
> > > The title comes from @HtmlDoc.title() or @RestResource.title() if not  
> > > specified (or the resource bundle or swagger file)  
> > > The description comes from @HtmlDoc.description() or  
> > > @RestMethod.description() if not specified (or the resource bundle or  
> > > swagger file).  
> > >  
> > > What I'd like to do is eliminate @HtmlDoc.title()/description()  
> > > /branding(),  
> > > and just add the following default value to the header() annotation on  
> > > RestServletDefault:  
> > > @RestResource(  
> > > htmldoc=@HtmlDoc(  
> > > header={  
> > > "<h1>$R{RestServlet.servletTitle}</h1>",  
> > > "<h2>$R{RestServlet.methodSummary}</h2>",  
> > > "<a href='http://juneau.apache.org'><img  
> > > src='$U{servlet:/htdocs/juneau.png}'></a>"  
> > > }  
> > > )  
> > > )  
> > >  
> > > This simplifies the logic and I believe makes it easier to understand  
> and  
> > > override in subclasses.  
> > >  
> >  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message