Another one,
We now have the basic mechanisms for the WindowId handling in place via
the method:
jsf.getClientWindow
However I miss the entire window Id handling in the jsf Ajax cycle itself.
Shouldn´t jsf.ajax.request send the client window identifier for the
issuing form (given by jsf.getClientWindow(form))
down, if one is present? Or is this an implementation detail which
should be left open to the implementer?
Kind regards
Werner Punz
Am 01.10.12 12:33, schrieb Werner Punz:
> 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/
>>
>>
>