Hi
2012/2/17 Edward Burns <edward.burns_at_oracle.com>:
> 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.
>
The problem here is we want to fix Flash scope with windowId concept, and that
initialization code occur before any phase listener. The only way to
fix it correctly
is inserting initialization code before flash scope init. This is one reason
why windowId should be include at spec level.
> 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.
>
Yes, it is relevant. Gerhard agrees with me in this point. I think the
post-phase code is also necessary.
> 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.
>
regards
Leonardo Uribe
>>>>>> 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/