[jsr-314-open-mirror] [jsr-314-open] javax.faces.ViewState + ppr case

[Werner Punz]

Actually I can only talk from the javascript side here.
The main issue is that a PPR response does not include
a ViewState element, instead the viewState is delivered
by the separate viewState xml element.

Here is how I bypassed the problem for now for MyFaces,
I simply check all elements which are processed (issuer, and updated ones)
for embedded forms, after the entire updating is done, and check if the
viewstate is set, if not
we have to attach the viewstate.

The limitation of this approach however is that if a user explicitely issues
a cross portlet render directive, there is no way this will work, but
however
if that is issued the entire lifecycle fails, because it simply is not part
of the viewRoot
which is processed. So this is a non issue for me.

So far this approach works really well, and I am finally able to do stuff
like this:

http://pastebin.com/TmFGtQyv

This is more or less the usecase the user had who pointed me towards this.
Not sure if this approach is valid within the spec (the TCK probably will
tell),
but it is a valid usecase which has to be covered.

In my opinion the spec here is at fault, and to my testing Mojarra also has
a similar bypass code
but it only works on direct form elements being rendered, instead of
checking for embedded forms also.


Werner




On Tue, May 11, 2010 at 11:18 PM, Martin Marinschek
<mmarinschek at apache.org>wrote:

> On 5/6/10, Alexander Smirnov <asmirnov at exadel.com> wrote:
> > Let me point out that Mojarra already takes care for state in AJAX
> > requests in the server-side saving. In the case of partial request,
> > ServerSideStateHelper ( see line 196 ) reuses view state and doesn't
> > change content of the javax.faces.ViewState parameter, so any request
> > from page should restore proper state because it has the same id as it
> > was rendered in AJAX request.
> > Therefore, that bug applicable for client-side state only, but updating
> > state parameter for ALL forms on the page could cause problem for portal
> > environment there each portlet keeps its own state that should not be
> > updated by requests from others...
>
> Interesting problem.
>
> So we are rendering multiple forms, and in one case, the forms belong
> to one application, and in another case, they are from different
> applications. How can we find out which forms belong to our
> application? Portal environments will namespace their content, but
> there is no way for us to find out - right? Would we need to keep
> track of our forms during rendering?
>
> best regards,
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100512/bd185f5a/attachment-0002.html