[jira] Updated: (MYFACES-883) ViewTag Write Behinds

["Mike Kienenberger (JIRA)" <de...@myfaces.apache.org>]

     [ http://issues.apache.org/jira/browse/MYFACES-883?page=all ]

Mike Kienenberger updated MYFACES-883:
--------------------------------------

    Description: 
Jacob Hookom wrote:

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.

Right now, ViewHandlers (Facelets and MyFaces) write out a temporary
place holder in the UI for client-state saving.  This is so after the
tree has rendered, *now* we serialize and write the state in.

Within Facelets, thise write-behind behavior occurs right within the
FaceletViewHandler.renderView method (really simple), the RI also does
this.

Within MyFaces, this write-behind occurs instead within the ViewTag.  So
you have the JspViewHandler writing the tokens with the expectation
that: 1) the developer uses a view tag, 2) the view tag will be able to
know about/replace stateful tokens provided by the JspViewHandler.
While this works fine for JSP, I hope others see the problem here in
the spirit of the JSF platform.

Secondly, the MyFaces ViewTag does write-behind on commandLinks within
the ViewTag.  There is a dependency now between the ViewTag, a
specialized StateManager, and the Renderer for the HtmlCommandLink.
I'm not sure the reasoning behind doing this, but there is possibly a
disconnect in the logic.

  was:
Jacob Hookom wrote:

Right now, ViewHandlers (Facelets and MyFaces) write out a temporary
place holder in the UI for client-state saving.  This is so after the
tree has rendered, *now* we serialize and write the state in.

Within Facelets, thise write-behind behavior occurs right within the
FaceletViewHandler.renderView method (really simple), the RI also does
this.

Within MyFaces, this write-behind occurs instead within the ViewTag.  So
you have the JspViewHandler writing the tokens with the expectation
that: 1) the developer uses a view tag, 2) the view tag will be able to
know about/replace stateful tokens provided by the JspViewHandler.
While this works fine for JSP, I hope others see the problem here in
the spirit of the JSF platform.

Secondly, the MyFaces ViewTag does write-behind on commandLinks within
the ViewTag.  There is a dependency now between the ViewTag, a
specialized StateManager, and the Renderer for the HtmlCommandLink.
I'm not sure the reasoning behind doing this, but there is possibly a
disconnect in the logic.


Added a missing summary message piece :)

> ViewTag Write Behinds
> ---------------------
>
>          Key: MYFACES-883
>          URL: http://issues.apache.org/jira/browse/MYFACES-883
>      Project: MyFaces
>         Type: Improvement
>   Components: Implementation
>     Versions: Nightly
>     Reporter: Mike Kienenberger

>
> Jacob Hookom wrote:
> 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.
> Right now, ViewHandlers (Facelets and MyFaces) write out a temporary
> place holder in the UI for client-state saving.  This is so after the
> tree has rendered, *now* we serialize and write the state in.
> Within Facelets, thise write-behind behavior occurs right within the
> FaceletViewHandler.renderView method (really simple), the RI also does
> this.
> Within MyFaces, this write-behind occurs instead within the ViewTag.  So
> you have the JspViewHandler writing the tokens with the expectation
> that: 1) the developer uses a view tag, 2) the view tag will be able to
> know about/replace stateful tokens provided by the JspViewHandler.
> While this works fine for JSP, I hope others see the problem here in
> the spirit of the JSF platform.
> Secondly, the MyFaces ViewTag does write-behind on commandLinks within
> the ViewTag.  There is a dependency now between the ViewTag, a
> specialized StateManager, and the Renderer for the HtmlCommandLink.
> I'm not sure the reasoning behind doing this, but there is possibly a
> disconnect in the logic.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira