OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Request for a "popup" windowstate



I deliberately did not make much of a proposal so that people could start by thinking through what the implications might be for the choices made in how their Consumer is implemented. Certainly the state management issues are different if the Consumer pushes the state to the user agent vs storing it and pushing references.

I'll try and take this from the portlet developer's perspective and work through the implications:
  1. The popup should be a distinct view onto the same portlet instance. This implies we would need to define how the Consumer connects up the various pieces of state:
  1. NavigationalState is associated with the view as this allows the views to evolve independently
  2. Mode is associated with the view (e.g. wsrp:help vs wsrp:view)
  3. WindowState is associated with the view. The windowState for the view in the popup should be restricted to wsrp:solo (or wsrp:maximized if solo is not supported, (i.e. validNewWindowStates is always empty))
  4. SessionID should be associated with the portlet instance so that interactions in either view impact the rendering of the other view.
  5. Cookies should be associated with the portlet instance.
  6. The two views should be able to communicate with each other (e.g. the address book filling in the recipient fields in an email compose view or notification of a render update that might cause a contextual help view to also update):
  1. Define a namespaced script variable in the "parent" view that holds the handle for the popup window
  1. Issue: What if a portlet throws off multiple popups over time? (=> make this variable always an array? Provide a hook for the portlet to have some script execute after the popup opens?)
  2. Define a script variable in the popup view that holds a handle for the subtree where the portlet's markup has been included.
  1. Issue: Is the namespace prefix for the portlet in the "parent" view also needed so that script functions may be invoked?
  2. Other issues/points:
  1. Does use of the wsrp:popup windowState require Consumer URL rewriting?
  1. Issue: The need to store the handles for cross-view communication likely requires the Consumer use scripting to open the popup. Allowing this windowstate to be specified with template processing likely requires that all urls be processed by some scripting whenever this windowstate is supported. This has implications on what a portlet can do in a "url".
  2. While the semantics of the windowState url parameter would be the opening of the popup window, the semantics of all other url parameters would apply to the view in the popup.

Rich Thompson
OASIS WSRP TC Chair
Interaction Middleware and Standards for Portal Server
IBM T.J. Watson Research Center / Yorktown Heights, NY
Phone: (914) 945-3225 / (203) 445-0384    email: richt2@us.ibm.com



Michael Freedman <michael.freedman@oracle.com>

04/12/05 11:32 AM

To
wsrp <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Request for a "popup" windowstate





Can you provide more specifics?  The complications with pop-ups vs other
window states is that developers commonly want this to be a second view
of the portlet -- I.e. the pop-up renders along with the portlet in the
page vs. it being a tear-off UI.  This complicates things because I
believe we should help facilitate state management if we add such
support.  State management is more complicated because you now need to
manage multiple mode states in a single state record.
   -Mike-

Rich Thompson wrote:

>
> We have heard back from portlet developers that a valuable UI
> technique they find missing in WSRP is the ability to request that
> activation of a url result in showing a portlet in a popup window.
> Common examples on the web today include:
>
>     * Popup window shows a "printer-friendly" view on the portlet's
>       markup (often missing ads, navigation menus and extraneous
>       graphics)
>     * Help ... both related to the portlet's functionality and a
>       glossary style definition of terms
>     * More sophisticated scenarios like showing an address book to set
>       email recipients (I know both Yahoo and Excite do this)
>
>
> Some more sophisticated scenarios use references to a different
> portlet, but I think reaching a consensus on how to do that with
> remote portlets within the v2 timeframe is unreasonable. I do think it
> would be reasonable to define a "popup" windowstate in v2 with the
> restriction that the portlet to be shown in the popup is the one whose
> markup contains the url causing the popup.
>
> Rich




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]