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...
On 05/06/2010 12:46 AM, Werner Punz wrote:
Hi I filed a bug report under
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790
But I would need further clarification regarding this issue, so that I
can move forward with a fix. Since a fix obviously would not break
anything (or unlikely at this stage), I´d rather fix it in the
2.0.1-SNAPSHOT codebase for MyFaces instead of having
to wait for a fix on the spec side.
But the fix behavior must be inline with the fixed functionality on the
spec side in this area, so that I do not program behavior in, which we
cannot expect, once this is fixed on spec level (and Mojarra also has to
fix this obviously)
Have in mind, this is a usecase, which can happen very often, especially
in a szenario, where javascript dialogs are used which have to rely on
position absolute, directly under the document element (due to IE6
having personal problems with position:fixed)
so a typical multi window szenario, where there are lots of embedded
frames in dialogs and the dialogs can be pushed through the ppr cycle...
Werner
On Wed, May 5, 2010 at 3:08 PM, Martin Marinschek
<mmarinschek(a)apache.org <mailto:mmarinschek@apache.org>> wrote:
Hi Werner,
I agree with you - a new view-state should lead to an update of this
state in all forms - not only the submitting one. The view-state
covers the state for the full _view_ and not the one of one _form_ -
everything needs to be updated - or submits from other forms will not
be possible anymore!
best regards,
Martin
On 5/5/10, Werner Punz <werner.punz(a)gmail.com
<mailto:werner.punz@gmail.com>> wrote:
> Hello I am asking this because this because I user ran into this
issue by
> using a dom modifying javascript widget and tried to press it through
> jsf.ajax.request.
> (aka a typical dialog widget)
>
>
> The issue is that there is a usecase where you try to execute a
ppr within
> one form
> and then try to render another form.
>
> aka:
>
> <h:form id="form1">
>
> ... jsf.ajax.request(this, event, {execute:"form1 form2",
render:"form2"});
> </h:form>
>
>
> <h:form id="form2">
> </form2>
>
> The main issue here is that after the request a javax.faces.ViewState
> element is issued in the ppr cycle. Now the spec says:
>
> If an update element is found in the response with the identifier
> javax.faces.ViewState:
>
> <update id="javax.faces.ViewState">
> <![CDATA[...]]>
> </update>
>
> locate and update the submitting form's javax.faces.ViewState
value with the
> CDATA contents from the response.
>
> Now this works coherently with a single form usecase because the
viewstate
> is issued on the submitting element.
> The main problem is, both implementations in this special case
have another
> behavior.
>
> if the form2 is rendered there is no viewstate element in the udate
> id="form2" but after that the viewState element is issued,
> now however myfaces swallows it entirely for form2 because of this
spec
> entry, mojarra updates it only if render:"form2"
> but if for instance
> <h:panelGroup id="outerFormGroup">
> <h:form id="form2">
> </form2>
> </h:panelGroup>
>
> and render:"outerFormGroup" then it is swallowed as well.
>
> I assume now following, since the viewState is viewRoot related,
should´t we
> simply update all form elements over the entire page with the new
viewState
> content and simply add this field for form elements where the
viewState
> control is not present?
> The other solution would be to update all forms where an execute
and rendere
> happend or at least a rendere happend inside (or as parent node of
the form)
>
> Werner
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces