After rethinking this entire issue I personally think we still have an
unresolved problem there which goes hand in hand with
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-861.
It is again the portlet case. As stated before on the jsf.js side we are
going to introduce a new function jsf.util.getWindowId(domNode) which
basically returns the windowId which is searched from a given dom node.
Now in normaly cases this function simply returns what it finds in the
inner forms or in the url and ignores the dom node entirely upon which it
has to start to search.
But the reason why I added this parameter simply is to handle the Portlet
case, and there I also stated that the ViewRoot then must be taken into
consideration.
The problem now simply is, that in the Portlet case we need a ViewRoot
marker.
or at least a marker which marks the Portlet. I dont think that either the
Portlet bridge or the Portlet spec specify a standardized way to mark the
ViewRoot or the Portlet boundaries correctly in the spec. (I have to check
the specs yet, can anyone confirm this before digging into them)
So this means we will need an extension on the portlet spec/portlet bridge
side as well or we are able to introduce such a marker on our side.
The other option would be an xhr callback, but for performance reasons this
is not advicable.
Werner
On Wed, Jan 18, 2012 at 10:47 PM, Jakob Korherr <jakob.korherr_at_gmail.com>wrote:
> Hi Ted,
>
> > Does the implementation use HTML5 Session Storage if that's available?
> Yes, it does, but I guess not in the same way ICEfaces does it.
>
> Actually the idea behind this is giving frameworks (JSF as well as CDI
> extensions) a standardized way with which they can plug their
> window-related stuff (e.g. @WindowScoped) into JSF. Also frameworks
> like ICEfaces will most certainly (need to) provide their own
> window-id calculation algorithm in order to make things work. For
> example, MyFaces CODI (and soon also Apache DeltaSpike) provide a
> couple of scopes that rely on a window-id. Currently different methods
> are used to accomplish retrieving a valid window-id from the browser,
> however, these will most certainly not work correctly if ICEfaces is
> around, b/c it does a lot of things different than what CODI expects
> from standard JSF. Here ICEfaces may provide an even better window-id
> calculation algorithm (because of its massive use of AJAX and
> browser-handling) and as a result also improve CODI's scopes, when
> they are used in conjunction.
>
> Thus introducing the window-id in JSF will boost the interoperability
> of JSF's various frameworks relying on some kind of a window-concept.
>
> A word about @WindowScoped: I don't know if we really should do that
> (now), given the fact that there already is CDI (+ extensions) which
> provide exactly this (see also JAVASERVERFACES_SPEC_PUBLIC-976). But I
> am actually not totally sure about that, so let's discuss it!
>
> Regards,
> Jakob
>
>
> 2012/1/18 Ted Goddard <ted.goddard_at_icesoft.com>:
> >
> > This looks very interesting -- it would make sense to include a
> > @WindowScoped annotation if the ID is available.
> >
> > Does the implementation use HTML5 Session Storage if that's available?
> >
> > One feature of the ICEfaces WindowScope is immediate cleanup when the
> > window is closed, but the implementation of this makes use of a
> > request sent during onunload, and I would say that this strategy
> > is not solid enough for the JSF standard. However, even if the
> > scope is not disposed immediately when desired, it would still
> > be useful in applications (so I'm arguing that we should define
> > @WindowScoped even if not all aspects of the scope are perfect.)
> > (Session termination would effectively be relied on for cleanup.)
> >
> > Cheers,
> > Ted.
> >
> >
> > On 2012-01-17, at 2:44 PM, Jakob Korherr wrote:
> >
> >> Hi experts,
> >>
> >> On behalf of Gerhard Petracek, Mark Struberg, Leonardo Uribe, Werner
> >> Punz and myself, I'd like to send you the window-id proposal, that we
> >> developed at MyFaces, using MyFaces CODI's window-id handling as basis
> >> [1]. This proposal contains the basic ideas (classes, methods,
> >> configuration modes,...) for introducing a window-id in JSF 2.2. You
> >> can find the related spec issue at [2].
> >>
> >> Please review! Further ideas, comments,... are appreciated. Thanks!
> >>
> >> Regards,
> >> Jakob
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal
> >> [2] http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-949
> >>
> >> --
> >> Jakob Korherr
> >>
> >> blog: http://www.jakobk.com
> >> twitter: http://twitter.com/jakobkorherr
> >> work: http://www.irian.at
> >
> >
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>