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
Now if we introduce a viewroot container client id, as far as I
understood the original discussion, we do not need that anymore, we do
only update the forms within the given viewroot (this would solve the
multiple forms problem as well), maybe I misunderstood the discussion
From what I can gather here, the Viewroot is not really used and we
default back to the original broken implementation of using render
targets and origin forms in a multiple form scenario. The question is,
given the original discussion of introducing this mechanism to be xml
correct for multiple forms, do we still need the render target mechanism
here, wouldnt it be simpler just to update all forms within a given
ViewRoot?
This would also resolve the broken multiple form scenario from the ajax
perspective.
Werner
Am 27.09.12 12:12, schrieb Werner Punz:
> I found a possible problem, in the Ajax cycle the newly introduced
> delay functionality is per default set to 300 if no delay is given.
>
> This might be problematic. It breaks the behavior of the existing
> functionality and might cause problems in component frameworks which
> rely on the existing behavior of being queued.
>
> My proposal would be just to make the delay optional only with none
> being the default if no delay is used.
>
>
> Werner
>
>
>
> On Mon, Sep 24, 2012 at 11:47 PM, Edward Burns
> <edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com>> wrote:
>
> Hello Experts,
>
> Here is the first draft of the JavaOne 2012 expert group draft spec
> snapshot.
>
> http://java.net/projects/javaserverfaces-spec-public/downloads/download/JSF_2_2/spec_snapshots/javax.faces-api-2.2-20120924.212754-61-javadoc.jar
>
> It's in maven.java.net <http://maven.java.net> at GAV
> javax.faces:javax.faces-api:2.2-SNAPSHOT,
> but I wanted it to stick around longer then their SNAPSHOT expiration
> policy so I put it in our download area.
>
> I'll very likely produce one more draft before JavaOne, but please
> take
> a look when you get a chance.
>
> Ed
> --
> | edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com> |
> office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> | homepage: | http://ridingthecrest.com/
>
>