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)

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.


On Thu, May 13, 2010 at 8:42 PM, Alexander Smirnov <> 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

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:
> 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
> < <>> wrote:
>     On 5/6/10, Alexander Smirnov <
>     <>> 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