myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Gary VanMatre)
Subject Re: Playing round with 1.5 features
Date Wed, 29 Mar 2006 18:11:30 GMT
>From: "Adam Winer" <> 
> On 3/29/06, Werner Punz wrote: 
> > Travis Reeder schrieb: 
> > > I'm all for anything that makes component writing easier, it's pretty 
> > > complex right now, so many places to make mistakes and makes it hard for 
> > > a newbie to start making components. 
> > > 
> > Actually there are two areas which components probably have to tackle 
> > api wise. 
> > a) The number of artefacts and glue code which are a huge burden 
> > b) The way the markup is generated. 
> > 
> > The renderers have the basic problem of having to handcode the markup 
> > via sending strings to writer objects. This gives maximum performance 
> > due to linear runtime complexity, but is a huge burden on the component 
> > developers. 
> > 
> > a split between data and markup rendering programmingwise would be saner. 
> > pushing the whole subrendering into something more readable would 
> > improve comfort. For instance if they subrendering could be pushed into 
> > something like velocity you suddenly would have the component, the 
> > bingings to the jsp or whatever subsystems and the renderer basically 
> > would be gathering data (mostly just pushing the component directly in) 
> > and then rendering it away via a sane templating markup. 
> I've long wanted to build a declarative rendering engine for JSF. 
> I wouldn't want to use Velocity per se or any other existing engine, 
> because you'd lose all of the ResponseWriter goodness (which is very 
> important for tooling) and any ability to embed other JSF components - 
> any decent JSF component templating engine will support reusing 
> existing JSF components, and you'd have to extend it to support 
> some additional JSF commands anyway (e.g., "render facet 'foo' here"). 

I've been playing with this idea of a renderer decorator (
This example has a specific goal and that is to inject some javascript into the onclick event
of a command component. The reason is to support the immediate attribute on a command when
using Shale commons validator and client side javascript validation. 

I thought that this could be made into a shale extension. Craig thought that we could insert
a custom response writer that build a DOM tree from the writer hooks. But I'm not sure how
we would handle the case where the component developer used a string buffer and the writer's
write method versus the startElement/writeAttribute methods.I assume that these methods are
the goodness that your talking about. This is the same idea as the buffer component but at
the renderer level.

What if velocity was used in the renderer. The velocity context was loaded with the target
JSF component and faces context. The template with merged and then the product template was
parsed with with an HTML/XML parser and the correct methods invoked on the response writer.

This is kind of the reverse role that Facelets and Clay adds. Probably too much overhead to
consider for more than a one off case.

I apologize if this is offtopic.


> > The main problem I see is performance, so in the end we probably are 
> > stuck with it or have to move over to client side componentization 
> > (which is the other approach, omit the api entirely as much as possible 
> > and move to a higher abstraction level like facelets do it) 
> The key thing is that you use raw Java code for all of the primitives, 
> and get their performance as optimal as possible; once that's done, 
> my hunch is that using a declarative engine only for some higher 
> level aggregates and seldom-used lower level components would have 
> relatively little impact on performance. (But as usual, this is an 
> abstraction vs. performance issue.) 
> -- Adam 
View raw message