> 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
This unfortunately is not entirely sufficient, the entire function can be
called
outside of the jsf lifecycle just for handling the windowId, hence I
anchored it in the
jsf.util namespace. Which means, the first call even could be made before
any
ajax call is made which can give the containerClientId back.
So we either have the option add a marker to the container or make an ajax
call which returns the container client id. First is no option in my
opinion.
> Isn't that sufficient? Werner, I'd greatly appreciate it if you could
> work up a patch that implements jsf.util.getWindowId() given the new
> requirement I just mentioned for <partial-response>
Sure, I have to do it in a way that I wont touch Mojarra code as you know,
I am not allowed to. The first part the non portlet case is easy, the
second part needs the extension, I will rely on an abstract
getContainerClientId
javascript function there, hence it will not work for that case initially
(we need to resolce issue 861 for that one).
So all I can provide is a standalone function for integration in both impls
under ASF or BSD license which should be sufficient for both
implementations. I will be able to provide it around the 27th of February,
if that is ok.
Werner
On Fri, Feb 17, 2012 at 11:09 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> TG> This looks very interesting -- it would make sense to include a
> TG> @WindowScoped annotation if the ID is available.
>
> JK> A word about @WindowScoped: I don't know if we really should do that
> JK> (now), given the fact that there already is CDI (+ extensions) which
> JK> provide exactly this (see also JAVASERVERFACES_SPEC_PUBLIC-976). But I
> JK> am actually not totally sure about that, so let's discuss it!
>
> Let's leave @WindowScoped out of this discussion for now.
>
> TG> One feature of the ICEfaces WindowScope is immediate cleanup when the
> TG> window is closed, but the implementation of this makes use of a
> TG> request sent during onunload, and I would say that this strategy
> TG> is not solid enough for the JSF standard. However, even if the
> TG> scope is not disposed immediately when desired, it would still
> TG> be useful in applications (so I'm arguing that we should define
> TG> @WindowScoped even if not all aspects of the scope are perfect.)
> TG> (Session termination would effectively be relied on for cleanup.)
>
> Ted, I'm going to trust you to make sure that this concern is adequately
> addressed in the spec that we end up with.
>
> >>>>> On Tue, 14 Feb 2012 10:52:26 -0500, Leonardo Uribe <lu4242_at_gmail.com>
> said:
>
> EB> Q.2 aside from before RestoreView, what other pre-phase actions
> EB> are required?
>
> LU> url-Mode: Try to detect if there is a windowId, decoding the data
>
> LU> client-Mode: Try to detect if there is a windowId, decoding the data
>
> LU> portlet-Mode: The portlet container should deal with windowId logic
>
> JK> ad Q2 and Q3: we use prePhase/postPhase stuff like FlashScope to keep
> JK> consistency inside the JSF spec + we may want to let an extension
> JK> point open for custom JSF frameworks (consider e.g. ICEfaces).
>
> I prefer to take advantage of the fact that we can modify the core
> specification and instead work these requirements straight into the
> lifecycle phases. In other words, I don't think we need an explicit
> prePhase action because we already have PhaseListeners for that.
>
> EB> Q.3 post-phase action is currently empty. What possible actions could
> EB> there be here?
>
> LU> The algorithms described does not have any possible action
> LU> contemplated, just the proposal include this call if something in the
> LU> future arise in this part and to keep symmetry in the code. For
> LU> example, if someone wants to create a wrapper for Window object and
> LU> implement a window scope, maybe this call could be useful to dispose
> LU> something.
>
> Again, because I'm not having a windowId specific post-phase method,
> this concern is no longer relevant.
>
> EB> I think Q.4 is the most pressing. Can someone answer me that one?
>
> LU> In my opinion FacesServlet is just something relatet to servlet case,
> LU> but JSF should be able to run in other environments like portlets.
>
> RS> For what it's worth, the FacesServlet is also not used in Web Flow's
> RS> integration with JSF. Rossen
>
> Thanks.
>
> >>>>> On Fri, 17 Feb 2012 08:46:29 +0100, Werner Punz <
> werner.punz_at_gmail.com> said:
>
> WP> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-861.
>
> WP> It is again the portlet case. As stated before on the jsf.js side we
> are
> WP> going to introduce a new function jsf.util.getWindowId(domNode)
>
> [...]
>
> WP> The problem now simply is, that in the Portlet case we need a
> WP> ViewRoot marker. or at least a marker which marks the Portlet. I
> WP> dont think that either the Portlet bridge or the Portlet spec
> WP> specify a standardized way to mark the ViewRoot or the Portlet
> WP> boundaries correctly in the spec. (I have to check the specs yet,
> WP> can anyone confirm this before digging into them)
>
> 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.
>
> Isn't that sufficient? Werner, I'd greatly appreciate it if you could
> work up a patch that implements jsf.util.getWindowId() given the new
> requirement I just mentioned for <partial-response>
>
> For my part, I'm going to post a coherent proposal for 949-WindowId this
> week.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>