> It certainly can't be called without first obtaining the jsf.js, which
> can't have been obtained without first making a request to the JSF
> runtime, which we are now in the process of making allocate and return a
> windowId upon first request. Please help me understand why simply
> looking in the most recently returned <partial-response> element,
> per-session of course, is insufficient.
The problem is
a) the window id can be stored within a url or a form and
b) the combination of this with Portlets and/or subscopes which handle
their own windowIds.
For the non Portlet cases we can store the window id easily by simply
having it set over the initial loading and probably simply by fetching it
from the url (like I did in the prototype or by searching for it in forms)
But for the Portlet/subscope case we have entirely different issues.
Multiple Portlets trying to load jsf.js, each of those portlets maybe
having a different viewroot identifier during its lifetime. All of them
setting the head parameter for the outputscript target.
Hence determination over the simple jsf.js include, like we do it for the
project stage, is out of the question.
The same goes for the window id over the url, since multiple Portlets can
have different window ids stored in their respective forms.
*First proposal (currently in the Wiki):*
In the proposal we have the function the function
jsf.util.getWindowId(node) instead of a simple jsf.util.getWindowId(). With
node being any arbitrary element under the current ViewRoot.
The function then walks up the dom until it hits the associated viewRoot in
case of multiple viewroots and then searches for its forms and/or looks
into the url for the windowid. Now in the portlet case this path is blocked.
Therefore we have the problem of having to have a connection with the
planned Portlet support in jsf.js,
if we want to deal with this in an automated manner. However in a second
thought this resolves the issue only for the portlet case not the subscope
case hence following proposal:
*However second (new) proposal*:
While writing this I had an idea to bypass the problem without adding a
burden to the user/framework and to resolve this for subscopes with
different window ids within the same page. The idea is not to care about
the boundary from our side, but to see the function as following:
jsf.util.getWindowId(node) with node being the upper search boundary for
the forms.
* If a unique window id is found then the function can return it,
* if more than one is found the function throws an error.
The additional burden for the user here is limited and I guess frameworks
which use multiple window ids per page now can deal with it in a proper
manner as well by simply managing their viewroots themselves.
That does not resolve issue 861, I still would love to have a proper
clientside viewroot access
from javascript for other reasons, but at least we can postpone the
resolution now independent of this issue.
Werner
On Mon, Feb 20, 2012 at 6:02 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> >>>>> On Mon, 20 Feb 2012 17:01:30 +0100, Werner Punz <
> werner.punz_at_gmail.com> said:
>
> >> Our solution to 220-ViewState made it so "id" is a required attribute of
> >> <partial-response> and its value is the return from
> >> UIViewRoot. getContainerClientId(), which, as Neil Griffin already
> >> affirmed, is guaranteed by the portlet bridge to meet the portlet
> >> uniqueness requirements
>
> WP> This unfortunately is not entirely sufficient, the entire function can
> be
> WP> called
> WP> outside of the jsf lifecycle just for handling the windowId, hence I
> WP> anchored it in the
> WP> jsf.util namespace. Which means, the first call even could be made
> before
>
> It certainly can't be called without first obtaining the jsf.js, which
> can't have been obtained without first making a request to the JSF
> runtime, which we are now in the process of making allocate and return a
> windowId upon first request. Please help me understand why simply
> looking in the most recently returned <partial-response> element,
> per-session of course, is insufficient.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>