ViewTag Write Behinds

[Jacob Hookom <ja...@hookom.net>]

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

Re: ViewTag Write Behinds

[Jacob Hookom <ja...@hookom.net>]

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

Re: ViewTag Write Behinds

[Martin Marinschek <ma...@gmail.com>]

> 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

Re: ViewTag Write Behinds

[Jacob Hookom <ja...@hookom.net>]

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 <ja...@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

Re: ViewTag Write Behinds

[Jacob Hookom <ja...@hookom.net>]

A lot of this was all spurred on by changes in *both* code bases around 
state management and identities.  The recent releases (1.0.4) should be 
working fine (again).

There were some questions around letting UIComponents (UICommands 
specifically) generate their own identities, but then people were 
emailing the Facelets list saying that they were now getting warnings 
from MyFaces that the user should specify ids (which shouldn't be 
necessary or an issue).

-- Jacob

Martin Marinschek wrote:

>Jacob,
>
>as we are in the discussion right now, Thomas Spiegl recently tried to
>use Facelets and gave up on a whole bunch of duplicate-id exceptions.
>
>He didn't try long though, so this doesn't have to say much ;).
>
>Is this something that might in any way be related to any of the open
>jira-issues on MyFaces and Facelets not working correctly together?
>
>regards,
>
>Martin
>
>On 12/15/05, Martin Marinschek <ma...@gmail.com> 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 <ja...@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
>>
>>    
>>
>
>
>--
>
>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

Re: ViewTag Write Behinds

[Martin Marinschek <ma...@gmail.com>]

Jacob,

as we are in the discussion right now, Thomas Spiegl recently tried to
use Facelets and gave up on a whole bunch of duplicate-id exceptions.

He didn't try long though, so this doesn't have to say much ;).

Is this something that might in any way be related to any of the open
jira-issues on MyFaces and Facelets not working correctly together?

regards,

Martin

On 12/15/05, Martin Marinschek <ma...@gmail.com> 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 <ja...@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
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: ViewTag Write Behinds

[Martin Marinschek <ma...@gmail.com>]

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 <ja...@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