On 3/29/06, Werner Punz <[EMAIL PROTECTED]> 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").

> 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

Reply via email to