I know you guys have been battling with a lot of bugs around components
and getting up to 1.1, so I apologize if I sounded harsh. Some of the
solutions that were pursued, while they may work, don't fit with the
solutions that the EG came up with around content interweaving and tree
creation (TCCI). The JSF 1.2 spec and other related implementation
resources are currently available and their something to be aware of as
you look to solve these incremental issues.
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.
--
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.
-- Jacob
Martin Marinschek wrote:
Sorry for the late answer,
I do think that most of what you are talking about has been in MyFaces
right from the beginning, so I think the situation is at least not
deteriorating, as your post suggests ;)
We haven't started implementing JSF1.2 so far (and the 1.2 spec didn't
even exist in early stages when the code you refer to (at least in the
ViewTag) was implemented), so I suppose it wasn't programmed
especially with this spec in mind.
Maybe you could help us out with a patch here which cleans this whole
thing up a little in a JSF1.2 compliant way? Would be great!
And - for clarification, are you just talking about the view-tag, or
also about other tags as well? I didn't quite get this from your post,
you talk about the view-tag first, and then it rather sounds general?
regards,
Martin
On 11/27/05, Jacob Hookom <[EMAIL PROTECTED]> wrote:
I've noticed in your recent releases that you've included a lot of
write-behind code within the JSP View Tag. What was the reason for
spreading the logic around between the individual component renderers,
JSP tags, and the JspViewHandler implementation? The state write-behind
could have just been contained within the JspViewHandler.
Also state-saving server w/ commandlinks doesn't work without using a
View Tag, because of the specialized URL write behinds. I don't
experience the commandLink issue with state-saving client.
*grump* JSF was designed to delegate controller concerns as
interchangeable blocks, and the implementation now seems to be
missmashed between specialized Application delegates. This will cause
issues when you start implementing JSF 1.2 as things like View and
SubView concepts are falling by the wayside as unecessary, also there
are quite a few other projects popping up that are exploring things like
AJAX such that the inter-dependencies between tags and components as a
processed whole, will basically not function with the MyFaces
implementation.
I don't want to sound like I'm in a poor mood, I just hope some of this
can be simplified and consolidated within the myfaces code base.
-- Jacob
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com
