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

[Martin Marinschek]

Hi all,

anyways, this behaviour is really broken in JSF as is - Mike is
absolutely correct here.

I once questioned Adam about this, and he said he isn't using multiple
forms, so he is not interested. But I do think emitting valid XHTML
should in all cases (also with multiple forms) be in our interest!

regards,

Martin

On 3/4/09, Alaxander Smirnov <asmirnov at exadel.com> wrote:
> In the RichFaces library, we have a 2 strategies ( they are different
> for the client and server side state savings ).
> First one, for a server-side state, we overwrote StateManager to keep a
> 'stateId' value a same during AJAX requests. Therefore, that value is
> not updated by AJAX requests. Otherwise server-side cache can be quickly
> overloaded what breaks browser back-button support.
> In the case of client-side state saving, a new state sent in the ajax
> response and updated by the client-side script everywhere on page.
> The portlet is a special case. Because portletbridge have to keep
> request state on the server for 'render' requests support, client-side
> state saving does not make sense. Because we do not update VIEW_STATE
> field value in this case, we have no namespace problems. Really, the
> client-side state saving is also supported but with a special hack: our
> bridge implementation renders <div> element with ID created from the
> portlet namespace. Client-side library updates hidden fields in the that
> element only.
> As I already wrote, the most common way to resolve namespace problems is
> special ResponseStateManager which should write namespace-prefixed view
> state hidden field for portlets. It is not necessary to include that
> class in the JSF spec, it may be included in the portlet bridge only.
> That class also solves the other portletbridge problem: parsing view
> state field in the StateManager instance, what looks like a  hack...
> Out of topic: Michael, is it ok for me to take part in the portlet
> bridge  meeting  on 03/04 ?
>
> michael freedman wrote:
>> 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
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces