That's great news!
I originally wrote Facelets just to work with JSF 1.2, but at J1, Adam
convinced me that MyFaces support would make or break Facelets. It was
a great decision to include support and we want to continue to support
MyFaces as best we can. In relation to JSF 1.2 and MyFaces, I think the
myfaces-dev group will be able to benefit from the headaches the JSF1.2
EG went through, Roger is an excellent resource.
-- Jacob
Martin Marinschek wrote:
The issue I ran into cascaded from: 'why does myfaces render a form
after my html tag?' to 'implementing state write behind within
FaceletViewHandler' to finding out that some HtmlComponents were
dependent on behavior from the MyFaces JspViewHandler and the
implementations StateManager. My first question becomes, well, what if
some other company (maybe Oracle) wanted to provide a different
StateManager and suddenly, 'standard' tags stopped working? It is a
cascading effect that should be avoided at all costs by guaranteeing that:
1) API and Implementation code bases are separated
2) Implementation Components only deal with API contracts, not locking
into MyFaces StateManager for ex.
righty, right. This is what all open bugs regarding ADF Faces and
Facelets are about. Needs to be fixed. Help is welcome!
Surrounding View creation, with JSF 1.2, view creation happens in two
steps: build tree, render tree. This is the sole responsibility of the
ViewHandler.
Your JspViewHandler would create a ResponseWrapper, capturing inlined
content within the JSP, include the target JSP-- producing a full
UIComponent tree that represents the whole page, with transient elements
representing inlined content.
The second step is simply asking the UIViewRoot (now populated) to
render itself, then doing State-writebehind on the rendered view and
finally sending down to the client.
So much of the lifting around missed-state during rendering or the stuff
that's coordinated in your ViewTag, would be done by any interchangable
ViewHandler.
Performance wise, the full tree creation doesn't cost you anymore than
before, secondly the rendering is still the same (same components)--
along with state saving. The only cost, really, is 'buffering' the
rendered output.
Yes - even without being able to implement 1.2 fully right now we were
planning to solve this ASAP. I also talked with Roger Kitain about
this today, we'll see when someone of us actually has the time to
implement it.
regards,
Martin
--
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com
