The window scope does not necessarily have to be shared over all
portlets. The windowId is just an identifier for the currently open tab,
there is no real underlying logic on how the scopes need to be bound to
this information.
So if the portlets need a windowscope, I guess the portlet logic should
rely on their own mechanism there which ultimately binds into the
portlet identifier and the window id.
I guess the user expects a window scope to be bound to a single portlet
since this is also the behavior for a standalone app. After all the
original idea to a portlet simply was that it is a standalone app being
displayed in part of a page.
But thats just my 2c as from a users point of view.
Werner
Am 02.03.12 17:40, schrieb Neil Griffin:
> Summary:
>
> I agree with Werner when he wrote "WindowId per portlet is not needed"
>
> Details:
>
> In a servlet environment @WindowScoped would be longer than
> @ViewScoped since multiple views could appear within the same window
> due to navigation-rules firing.
>
> The same would be true for a single portlet in a portlet environment.
>
> If the window-id is common/reused by all portlets on a page, then I
> think that would imply that @WindowScoped is a kind of "shared" scope
> by all of the portlets on the portal page.
>
> If all portlets on a page were in a single WAR file, then the new
> ExternalContext.getWindowMap() could use the
> PortletSession.ApplicationScope [1] to achieve this shared type of
> scope. I think this would be a natural addition to JSF for portlets,
> because it would provide a perfect JSF scope for facilitating
> Inter-Portlet Communication (IPC) with Ajax Push. It would also be a
> natural addition because the Portlet Bridge Spec requires
> ExternalContext.getSessionMap() to use PortletSession.PortletScope [2]
> which prevents sharing of data between portlets with @SessionScoped.
>
> If the portlets on a page were in two or more WAR files, then the
> Portlet Bridge would have to leverage portal-vendor-specific
> mechanisms for sharing data between portlets for
> ExternalContext.getWindowMap(). Otherwise @WindowScoped could not be
> shared by the portlets on the page. I think that's a limitation that
> developers can live with, because they already live with that problem
> today. The next version of the Portlet Spec (successor to Portlet 2.0
> JSR 286) would have to overcome that limitation first before we could
> address it in a Portlet Bridge.
>
> Regarding (h) window-id per Portlet
>
> If each portlet had its own window-id, then I think that would imply
> that @WindowScoped is NOT a scope that is shared by each portlet on
> the page. Werner asked "is there a use case for that one?" Yes indeed!
> But since this breaks the new tab detection jsf.getWindowId I would
> recommend that the use-case be handled in a different way.
> Specifically, the Portlet Bridge could permit the developer to specify
> a web.xml or portlet.xml init-param that
> instructs ExternalContext.getWindowMap() to use the same approach as
> the underlying JSF implementation, meaning, a managed sub-scope of
> ExternalContext.getSessionMap().
>
> (BTW, please be merciful to me for suggesting another init-param) hehe :-)
>
> [1]
> http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletSession.html#APPLICATION_SCOPE
> [2]
> http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletSession.html#PORTLET_SCOPE
>
>
> Neil
>
> On Mar 2, 2012, at 5:07 AM, Werner Punz wrote:
>
>> There was a small error:
>>
>> 1 Status quo CODI:
>> ------------------------------------------------
>>
>> should mean
>>
>> 1 Suggestions based on the status in CODI:
>> ------------------------------------------------
>>
>> Outside of that everything is correct now from my side.
>>
>> Werner
>>
>>
>> On Fri, Mar 2, 2012 at 10:31 AM, Werner Punz <werner.punz_at_gmail.com
>> <mailto:werner.punz_at_gmail.com>> wrote:
>>
>> Hello everyone since the discussion goes into various directions
>> and there were some errors in most recent proposal
>> which then dragged themselves into the codebase, I had a really
>> long IRC discussion with the CODI guys who did the initial
>> proposal (and are not part of the EG) on IRC who asked me to
>> speak here on their behalf. To get things mostly right this time.
>>
>> Hence here is an updated proposal which fixes the issues which
>> were accidentally pushed in. (WindowId per portlet is not needed)
>>
>> https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal
>>
>> And here is a summary as baseline for discussions/questions and
>> future revisions where CODI stands and the proposal and where we
>> stand in the discussion. This is a baseline document which will
>> be revisioned in the future to keep things together. Since the
>> entire windowId stuff is if you try to cover the corner cases
>> rather complex.
>> I am not sure if I have covered our area fully correctly, but we
>> can roll future revisions of this document.
>> So please read the proposal first and then the document here. And
>> also feel free to ask the CODI guys, if things are unclear. You
>> can meet them on the ##jsf and #myfaces channel or I will be
>> happy to forward questions and answers (they monitor this list
>> anyway)
>>
>>
>>
>> 1 Status quo CODI:
>> ------------------------------------------------
>>
>> 1.1 General Definitions regarding Window-ID
>> ------------------------------------------------------------
>> a) a window-id always refers to the tab (because it should/can be
>> stored in the browsers window.name <http://window.name/>)
>>
>> b) a window-id always is unique in the session of the user. A
>> session contains exactly 1 window-id per browser tab.
>>
>> c) rendering multiple window-ids per browser tab is not allowed
>> hence also not in portlet mode.(because the window-id is stored
>> in the browsers window.name <http://window.name/>)
>>
>>
>> 1.2 Modes and special cases
>> ---------------------------------------
>> 1) no mode: no window-id is generated - legacy mode
>>
>> 2) url-Mode: the window-id is stored in the browser url
>> hidden fields are shadowed into the forms also to keep the
>> window-id support for post requests.
>> windowId parameters are added to http get links.
>> Server side the windowId needs to be processed over the sent
>> windowId parameters.
>>
>> This is even the same for Portlet cases since the window-id has
>> a referential pattern of 1:n to the scopes
>> The same goes for sub scopes.
>>
>> If a new tab is opened a Javascript script detects that use case
>> and basically re-renders the page with a new window-id dedicated
>> to the tab.
>> How that is done is up to the implementation. The basic
>> implementation is to check for an empty or non-matching
>> window.name <http://window.name/> and then redirect the page
>> without a window-id in the url to force a new one.
>>
>> 3) custom-Mode:
>> Allows to use a custom mode provided by the JSF implementation or
>> a custom RenderKit.
>> Value: custom:[name of the mode]
>> TBD
>>
>> 5) Bookmark case or a href
target=_new: This is handled in CODI
>> by opening a new window-id or recycling the old one (bookmarking
>> case with same windowid in the bookmark as the existing one)
>>
>>
>> 2. Status quo of the spec discussion compared to CODI:
>> ---------------------------------------------------------------------------
>>
>> a) URL mode: checked is discussed.
>>
>> b) overriding the URL not yet fully discussed: since it opens
>> another can of worms (f)
>>
>> c) synchronizing the URL with hidden fields: checked is discussed
>> due to having hidden fields holding javay.faces.windowId
>>
>> d) Open in new tab script: soon under discussion
>>
>> e) hidden field only mode: Breaks e.g. the get requests and
>> browser refresh, therefore not doable
>>
>> f) jsf.getWindowId can be simplified (is now in the proposal) if
>> (b) is omitted or postponed, otherwise it needs to be
>> investigated, if the current implementation can hold. The entire
>> code was programmed under the assumption that we have a window-id
>> per Portlet use case, which cannot hold for (d) see also (g)
>>
>> g) Ajax protocol ViewRoot either redundant, or in case of (b),
>> cannot work on ViewRoot level
>> because single forms can if override is enabled be updated with
>> different ViewRoots.
>> (my mistake i was under the wrong assumption between window-id
>> and scope and because of (g) )
>>
>> h) window-id per Portlet, is there a use case for that one?
>> Especially since it breaks the new
>> tab detection jsf.getWindowId can hold for (g)
>>
>> i) server side part of the window-id handling, where to be
>> rendered, under discussion
>>
>> h) open point: what to do with the a hrefs and pages where you
>> donīt want to have a window id. Should a link to a different
>> window-id be possible, how can you turn it off/on.
>>
>>
>>
>>
>>
>