wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Request for a "popup" windowstate
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Tue, 12 Apr 2005 13:12:43 -0400
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:
- 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:
- NavigationalState is associated
with the view as this allows the views to evolve independently
- Mode is associated with the
view (e.g. wsrp:help vs wsrp:view)
- 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))
- SessionID should be associated
with the portlet instance so that interactions in either view impact the
rendering of the other view.
- Cookies should be associated
with the portlet instance.
- 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):
- Define a namespaced script variable
in the "parent" view that holds the handle for the popup window
- 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?)
- Define a script variable in
the popup view that holds a handle for the subtree where the portlet's
markup has been included.
- Issue: Is the namespace prefix
for the portlet in the "parent" view also needed so that script
functions may be invoked?
- Other issues/points:
- Does use of the wsrp:popup windowState
require Consumer URL rewriting?
- 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".
- 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]