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

[Werner Punz]

Yes exactly that is the problem here.

And as per spec if you issue a separate viewstate response element from the
server it is not attached to the newly rendered form but only to the issuing
one (see the corresponding
link I posted in my first mail regarding this).

Mojarra bypasses this problem, but only if the form itself is rendered if it
is embedded then it
is lost as well.

The question for me is are we dealing here with implementation issues
or is the spec here it fault?

Here is an example two forms
the lower form making a cross form submit
(run on Mojarra 2.0.2)

http://pastebin.com/p482gi5L

As you can see the rendered panel embeds a form, and the embedded form does
not have any viewstate
instead the viewstate is issued afterwards within the <update
id="javax.faces.ViewState"> section
where the spec clearly says only the issuing form will be updated.

The problem now is that the resulting html clearly has no viewstate element
in that case, unless the javascript
bypasses the problem and also attaches the viewstate issued to any updated
form which has a lost viewstate.

This is a situation which only can occur with cross form submits, because in
single form submits the separately issued viewstate will
correctly be attached to the issuing form which also is the updated one.

I am not sure if it was meant to be that no ViewState is sent within the
forms (probably due to lifecycle reasons in the client side case), but
Mojarra and MyFaces behave the same in this case both loose their viewstate
under cross form ppr cases.

As I said before Mojarra seems to have also some javascript side fixup code
in place, but that one just triggers
if the updated element itself is a form. If you embed it in a panel than it
fails.
I fixed that by checking for embedded forms in any level of the updated
subtree and if there was a viewstate element missing it is added. Sort of
what Mojarra does but by checking deeply int the dom tree instead of just
checking if it was a form element.

But I am still not convinced that fixing this on the javascript side is the
correct way to do it.
So either the spec here is at fault, which would then by my client side fix
I did,
or we have to fix both implementations server side.

Werner

On Thu, May 13, 2010 at 8:42 PM, Alexander Smirnov <asmirnov at exadel.com>wrote:

> Oh, I got the real meaning of that issue. Do you mean what if we append
> new form by AJAX, it does not contain viewstate at all, so it is not
> possible to submit view from such form ? This is real bug, view state
> hidden parameter should be rendered for any case, including partial
> response.
>
> On 05/12/2010 11:28 AM, Werner Punz wrote:
> >
> > 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 <mailto:mmarinschek at apache.org>> wrote:
> >
> >     On 5/6/10, Alexander Smirnov <asmirnov at exadel.com
> >     <mailto: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/20100513/939ce181/attachment-0002.html