jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [220-ViewStateParamNameOnly] PROPOSAL

From: Alexander Smirnov <alsmirnnov_at_gmail.com>
Date: Wed, 1 Feb 2012 11:06:09 -0800

Some time ago, I thought about moving from navigation by only DOM id to use
Xpath/CSS selectors. It would solve a lot of problems, including selective
update of view state hidden fields, partial updates inside complex
components, in style like:
<update select="id('portlet:root')//_at_name='javax.faces.ViewState'"><![
CDATA[-1470762710634119679:-9198324743075498445]]></update>
or
<update select="#portlet:root [name=javax.faces.ViewState]"><![
CDATA[-1470762710634119679:-9198324743075498445]]></update>

I only afraid that adding such feature requires too much effort on both
server and client side :-(

On Wed, Feb 1, 2012 at 6:54 AM, Rossen Stoyanchev <rstoyanchev_at_vmware.com>wrote:

> Hi Ed,
>
> In addition to the scenario with portlets described below, there are other
> cases where it is desirable to update "javax.faces.ViewState" hidden fields
> selectively rather than wholesale across the DOM.
>
> In Web Flow we support launching a wizard in a modal dialog. The modal
> dialog is really just a JavaScript overlay over the underlying page with
> Ajax updates refreshing the content of that modal dialog while the user
> progresses through the wizard. Once done the modal dialog is dismissed and
> they're back to the original form. Essentially there are two independent
> forms, the one of the modal dialog and the one from which the modal dialog
> originated. That doesn't work when Web Flow is used with JSF because Ajax
> requests update all ViewState hidden fields. It would be great if Ajax
> updates took care to update only those "javax.faces.ViewState" hidden
> fields that belong to the ViewRoot that processed the request.
>
> Rossen
>
> ------------------------------
>
> *From: *"Neil Griffin" <neil.griffin_at_portletfaces.org>
> *To: *"Edward Burns" <edward.burns_at_oracle.com>
> *Cc: *jsr344-experts_at_javaserverfaces-spec-public.java.net
> *Sent: *Tuesday, 31 January, 2012 4:37:00 PM
> *Subject: *[jsr344-experts] Re: [220-ViewStateParamNameOnly] PROPOSAL
>
>
> Hi Ed,
>
> I believe that my endorsement of Ted's first suggestion still applies.
>
> Agreed, all forms that are under the same ViewRoot will have the same
> ViewState. But a portal page will contain a ViewRoot for each JSF portlet,
> and so the value of the "javax.faces.ViewState" hidden field will be
> different for each ViewRoot.
>
> For example, the following portal page has two JSF portlets on it
> (Customers and Bookings):
>
> http://www.portletfaces.org/projects/portletfaces-bridge/examples/jsf2-ipc-events
>
> If you view the source of the page, you will see the are two hidden fields
> with id "javax.faces.ViewState" but each of the hidden fields have a
> different value.
>
> Using this example, the issue that Alexander was describing was that
> jsf.js has the potential of doing a partial DOM update on _both_ hidden
> fields, whereas it should only update _one_ of them. This can happen when
> the hidden field is the only thing being partially updated via the ajax XML
> transport. (this is exactly Ted's example below). In such a case, jsf.js
> needs to operate with "id" of the hidden field (not the id of some
> surrounding form). If the value of the "id" attribute were namespaced, then
> Alexander's issue would be solved. It would also solve the problem of
> uniqueness of each "id" attribute in the rendered HTML document.
>
> But actually there is a larger issue, probably worthy of its own thread,
> but I'll mention it here. The assumption that jsf.js makes is that there
> can be only one ViewRoot on a rendered HTML document. During partial
> updates in which the javax.faces.ViewRoot is being replaced in the DOM
> (which is basically a full update of the view -- not really partial),
> jsf.js attempts to replace everything inside the <body></body> elements. In
> a portlet environment, that would equate to the entire portal page getting
> replaced, wiping out all the other portlets. Note that I worked around this
> problem by having a custom ResponseWriter in the portlet bridge that
> "filters" the response that generates the XML transport. Need to solve this
> issue in JSF 2.2 for portlet alignment.
>
>
> Neil
>
> On Jan 31, 2012, at 2:57 PM, Edward Burns wrote:
>
> On Mon, 30 Jan 2012 08:46:08 -0700, Ted Goddard <ted.goddard_at_icesoft.com>
> said:
>
>
> TG> If the value can be modified after the page is initially rendered,
> TG> then it should have both a name "javax.faces.ViewState" and an
> TG> ID determined by the naming container hierarchy so that the following
> TG> works correctly:
>
> TG> <update
> id="javax.faces.ViewState"><![CDATA[-1470762710634119679:-9198324743075498445]]></update>
>
> TG> Or, javax.faces.ViewState should be handled as a special case, with
> TG> all forms from the same view updated together.
>
> Let me clarify. It is certainly the case that all the forms in the page
> will have the same value for the ViewState. Note that in the ajax XML
> transport, we still use "id" and not name. This change only impacts the
> hidden field.
>
> NG> +1 for Ted's first suggestion: Keep the ID attribute, and take it
> NG> one step further by prepending the naming container hierarchy (all
> NG> the way up to PortletNamingContainerUIViewRoot). That would solve
> NG> the XML requirement of all IDs being unique on a page, and guard
> NG> against any portlet problems too.
>
> Neil, does Ted's suggestion, and your endorsement of it, still apply
> even after the clarification I made above?
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>
>
>
>


-- 
_________________
entia non sunt multiplicanda praeter necessitatem,
(entities should not be multiplied beyond necessity.)