Adam Winer wrote:
My assumption is that the initial arrival will be akin to Tobago,
part of MyFaces, yes, but a third set alongside Tomahawk
and Tobago.
This of course raises major questions going forward of how
to integrate all of these into one coherent set - and, of course,
the question of whether to integrate at all (default answer - yes).
These aren't new questions for MyFaces - it already exists within
the context of Tomahawk + Tobago, but it does make it an
even bigger and tougher issue.
BTW, yes, we've got our own ViewHandler (currently registered
implicitly via META-INF/faces-config.xml). The big nastiness
with all these ViewHandlers is that ordering effects can be distinctly
nasty to work with. The best thing to do, IMO, will be writing a single
powerful ViewHandler with lots of separte, well-defined pluggability
points. We do some of this sort of stuff already with a Service
API that lets you define optional interfaces on a RenderKit that'll
get called as needed by the ViewHandler - no private IP being
revealed here, just google "ExtendedRenderKitService" for
a taste of the idea :)
Well the best issue probably would be to get rid of the view handler
depencencies at component level at all. One of the biggest problems is
the pattern used by the view handlers (decorators), it is rather hard to
combine those.
Add to that the problem, that facelets and tapestry also use theirs.
One good thing about the Tomahawk components is, they do not use
any custom view handler at all, so the integration of Tomahawk into
other jsf implementations and libraries is rather straigforward.
I am not sure if the view handlers of tobago and adf are needed that way
anymore, maybe something like facelets would be a better approach
(everyone seems to settle on that one as it looks currently)
To my understanding Tobago used its own view handler to get rid of jsp
tags and to use its own layouting mechanism, maybe there is a huge
redundancy there.
