>>>>> On Mon, 01 Oct 2012 12:33:33 +0200, Werner Punz <werner.punz_at_gmail.com> said:
WP> Ok I found another issue jsdoc section ViewState handling:
>> If an |update| element is found in the response with an identifier
>> containing |javax.faces.ViewState|:
>> |<update id="<VIEW_ROOT_CONTAINER_CLIENT_ID><SEP>javax.faces.ViewState<SEP><UNIQUE_PER_VIEW_NUMBER>">
>> <![CDATA[...]]>
>> </update>|
>> locate and update the submitting form's |javax.faces.ViewState| value
>> with the |CDATA| contents from the response. <SEP>: is the currently
>> configured |UINamingContainer.getSeparatorChar()|.
>> <VIEW_ROOT_CONTAINER_CLIENT_ID> is the return from
>> |UIViewRoot.getContainerClientId()| on the view from whence this state
>> originated. <UNIQUE_PER_VIEW_NUMBER> is a number that must be unique
>> within this view, but must not be included in the view state. This
>> requirement is simply to satisfy XML correctness in parity with what
>> is done in the corresponding non-partial JSF view. Locate and update
>> the |javax.faces.ViewState| value for all forms specified in the
>> |render| target list
WP> Now if we introduce a viewroot container client id, as far as I
WP> understood the original discussion, we do not need that anymore, we do
WP> only update the forms within the given viewroot (this would solve the
WP> multiple forms problem as well), maybe I misunderstood the discussion
But we *have* introduced the VIEW_ROOT_CONTAINER_CLIENT_ID. There is no
"if".
"We do not need that anymore", I'm sorry, what do you mean by "that"?
WP> From what I can gather here, the Viewroot is not really used and we
WP> default back to the original broken implementation of using render
WP> targets and origin forms in a multiple form scenario. The question is,
WP> given the original discussion of introducing this mechanism to be xml
WP> correct for multiple forms, do we still need the render target mechanism
WP> here, wouldnt it be simpler just to update all forms within a given
WP> ViewRoot?
At this point, I'm not sure. Given where we are in the schedule, unless
you feel that the current draft specification is broken, I'd really like
to keep it as is.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/