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

[Werner Punz]

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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100506/5c299d22/attachment-0002.html