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/