[jsr-314-open] Issue? Uniqueness of the ViewState parameter id.

michael freedman michael.freedman at ORACLE.COM
Tue Mar 3 20:33:56 EST 2009


By the way, how are JSF Ajax solutions dealing with the multi-form case
in JSF 1.2?  Is there a consistent strategy?  Is it often overlooked?
For all on the list, for whatever environment you know the strategy for,
please post.  I will collate into a matrix, afterwards.
    -Mike-

Roger Kitain wrote:
> For Ajax, here is what we do w.r.t javax.faces.viewState:
>
> If an update element is found in the response with the identifier
> javax.faces.ViewState:
>
> <update id="javax.faces.ViewState">
>   <![CDATA[...]]>
> </update>
>
> Include this state in the document as follows:
>
>    * Extract this <update> element's CDATA contents from the response.
>    * If the document contains an element with the identifier
> javax.faces.ViewState replace its contents with the CDATA contents.
>    * For each <form> element in the document:
>          o If the <form> element contains an <input> element with the
> identifier javax.faces.ViewState, replace the <input> element contents
> with the <update> element's CDATA contents.
>          o If the <form> element does not contain an element with the
> identifier javax.faces.ViewState, create an <input> element of the
> type hidden, with the identifier javax.faces.ViewState, set its
> contents to the <update> element's CDATA contents, and add the <input>
> element as a child to the <form> element.
>
> -roger
>
> michael freedman wrote:
>> Alexandr is also right, there maybe Ajax related problems as well at
>> least in the portlet case.  Doesn't the PPR processing need to update
>> the ViewState after a partial request?  Do we expect (by spec) all
>> impls to manage the viewstate in a javascript variable and have the
>> various hidden fields pull this value on full page submits?  Or might
>> impls try and push the updated ViewState into the hidden field?  If
>> the later won't they have problems in a multi-form page?  If the
>> former, what can we do to account for the portlet situation where I
>> have multiple portlets on a page each with distinct ViewState?  I.e.
>> if the portlet renders a JSF view its ViewState is distinct from
>> another portlet (rendering a JSF view) incorporated into the page.
>>    -Mike-
>>
>> Pete Muir wrote:
>>> At least in JSF1.2 Mike is correct, the hidden form field written
>>> out to set the viewstate parameter has the same id for each form,
>>> which means the HTML is not well formed and would not pass an HTML
>>> validator.
>>>
>>> I remember coming across this before and raising it with someone -
>>> perhaps Ryan or Ed?
>>>
>>> On 26 Feb 2009, at 21:19, Alexandr Smirnov wrote:
>>>
>>>> Faces allows as many form on page as you wish. The fields with
>>>> state do
>>>> not mixeed as they as are unique per form. This is not a problem for
>>>> Portlet applications, because only one hidden field submitted by form.
>>>> But that could be problem for an AJAX case,  there  client-side script
>>>> have to found appropriate state field to include in
>>>> HttpServletRequest.
>>>>
>>>> michael freedman wrote:
>>>>> From the looks of things in JSF 1.2 (and I imagine this hasn't
>>>>> changed
>>>>> in 2.0), JSF's hidden field holding the view state parameter is
>>>>> written using a static id/name.  I.e. the id of the field isn't
>>>>> namespaced by its containers.  Though not a common case, Faces does
>>>>> allow multiple (separate) form tags in a page, right?  In that
>>>>> situation aren't we violating strict HTML rules requiring id
>>>>> uniqueness?  Why does the id need to be static?  Can't we make this
>>>>> unique?
>>>>>   -Mike-
>>>
>>> --
>>> Pete Muir
>>> http://www.seamframework.org
>>> http://in.relation.to/Bloggers/Pete






More information about the jsr-314-open-mirror mailing list