myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Hookom <ja...@hookom.net>
Subject Re: ViewTag Write Behinds
Date Thu, 15 Dec 2005 02:06:02 GMT
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 <jacob@hookom.net> 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


Mime
View raw message