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:25:02 -0400
This sure got mangled as it went through
the OASIS mail handler ... here is an attempt to make it more reasonable.
Rich
Rich Thompson/Watson/IBM@IBMUS
04/12/05 01:12 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
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.a.
NavigationalState is associated with the view as this allows the views
to evolve independently
1.b.
Mode is associated with the view (e.g. wsrp:help vs wsrp:view)
1.c.
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))
1.d.
SessionID should be associated with the portlet instance so that interactions
in either view impact the rendering of the other view.
1.e.
Cookies should be associated with the portlet instance.
2. 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):
2.a.
Define a namespaced script variable in the "parent" view that
holds the handle for the popup window
2.a.i. 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.b.
Define a script variable in the popup view that holds a handle for the
subtree where the portlet's markup has been included.
2.b.i. Issue: Is the namespace prefix for
the portlet in the "parent" view also needed so that script functions
may be invoked?
3. Other
issues/points:
3.a.
Does use of the wsrp:popup windowState require Consumer URL rewriting?
3.a.i. 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".
3.a.ii. 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
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]