Thanks to everyone who contributed to this thread.
I'm only including replies that disagreed with my initial proposal to
simply drop the id attribute.
This reply includes a modification to the XML response format for Ajax.
>>>>> 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,
The ViewState is sent down fresh with every response from the server,
so, yes, it is 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>
Ted, your example disagrees with your recommendation. I must be
misunderstanding you. If we were to follow your recommendation, we
would have something like
<update id="j_idt324"><![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.
But that *is* how we currently handle it. There is one and only one
view state and it's the same value regardless of how many forms there
are on the page.
>>>>> On Mon, 30 Jan 2012 19:58:46 -0500, Neil Griffin <neil.griffin_at_portletfaces.org> said:
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.
Ahh, if that's what Ted was suggesting, it wasn't clear to me. But now
I can understand.
EB> Neil, does Ted's suggestion, and your endorsement of it, still apply
EB> even after the clarification I made above?
NG> I believe that my endorsement of Ted's first suggestion still applies.
NG> Agreed, all forms that are under the same ViewRoot will have the
NG> same ViewState. But a portal page will contain a ViewRoot for each
NG> JSF portlet, and so the value of the "javax.faces.ViewState" hidden
NG> field will be different for each ViewRoot.
I see. Thanks for clarifying so I can understand. But how can we
ensure that all the ViewRoots are unique?
Looking into the Portlet Bridge API, I see
PortletNamingContainerUIViewRoot, which overrides
getContainerClientId(). Neil, can you please confirm that if I have
multiple ViewRoots in my portlet page, the UIViewRoot for each of them
will actually be an instance of your PortletNamingContainerUIViewRoot,
and therefore is safe to ask it for getContainerClientId()?
I'll assume so.
RS> In addition to the scenario with portlets described [elsewhere],
RS> there are other cases where it is desirable to update
RS> "javax.faces.ViewState" hidden fields selectively rather than
RS> wholesale across the DOM.
RS> In Web Flow we support launching a wizard in a modal dialog. The
RS> modal dialog is really just a JavaScript overlay over the underlying
RS> page with Ajax updates refreshing the content of that modal dialog
RS> while the user progresses through the wizard. Once done the modal
RS> dialog is dismissed and they're back to the original
RS> form. Essentially there are two independent forms, the one of the
RS> modal dialog and the one from which the modal dialog
RS> originated. That doesn't work when Web Flow is used with JSF because
RS> Ajax requests update all ViewState hidden fields. It would be great
RS> if Ajax updates took care to update only those
RS> "javax.faces.ViewState" hidden fields that belong to the ViewRoot
RS> that processed the request.
Ok, here's the revised proposal.
* Change the javadoc of ResponseStateManager.VIEW_STATE_PARAM:
Index: jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java
===================================================================
--- jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java (revision 9649)
+++ jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java (working copy)
@@ -78,9 +78,15 @@
/**
* <p><span class="changed_modified_2_0
- * changed_modified_2_2">Implementations</span> must use this value
- * as the name of the client parameter in which to save the state
- * between requests.</p>
+ * changed_modified_2_2">Implementations</span> must use this constant field
+ * value as the name of the client parameter in which to save the state
+ * between requests. <span class="changed_added_2_2">The <code>id</code>
+ * attribute must be a concatenation of the return from
+ * {_at_link javax.faces.component.UIViewRoot#getContainerClientId}, the
+ * return from {_at_link javax.faces.component.UINamingContainer#getSeparatorChar},
+ * and this constant field value.</span>
+ *
+ * </span></p>
* <p class="changed_added_2_0">It is strongly recommend that
* implementations guard against cross site scripting attacks by at
* Change the contract for the Ajax XML response to require that the
<partial-response> element now have an "id" attribute whose value is
the return from UIViewRoot.getContainerClientId()
I realize this may need to be revised when we take up 949-WindowId.
The full patch is at
<
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220>.
NG> But actually there is a larger issue, probably worthy of its own
NG> thread, but I'll mention it here. The assumption that jsf.js makes
[...]
NG> transport. Need to solve this issue in JSF 2.2 for portlet
NG> alignment.
Thanks for bringing that up. Can you please search for an existing
isuse and bring it to us here? If you don't find one can you please
create one and bring it to us here?
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/