We had explicitly excluded from v1 defining
how a Portlet can control the construction/behavior of Consumer pages.
I do not see a compelling case for revisiting this decision for this particular
case of accessing an external help system. There is no chance this can
be well designed and worked through without a significant delay of v1 and
the Producer can certainly provide the functionality the Portlet desires
in this area.
A Portlet that wishes to provide help
such that a separate help window tracks the navigation in the "main"
window has some work to do with the v1 protocol, but I think it can manage
such transitions (it would require some signaling between the two windows
on the client device, but that is not too difficult).
Overall, I do not see a compelling reason
to let the scope of the v1 protocol expand in this area.
Rich Thompson
Alejandro Abdelnur <>
03/18/2003 04:40 PM
To:
cc:
Subject:
[wsrp] Re: Handling HELP
Comments embedded.
Alejandro
Rich Thompson wrote:
>I see two concerns being raised and would like to address them separately:
>
>1. Ability of a Portlet to use an external Help system (either as a
system
>or a set of static pages).
> This is certainly doable either using proxied
resources or the
>portlet managing the connection to the external system. The Producer
>certainly could manage such connections for the Portlet and thereby
reduce
>the repeated implementation of the functionality. If this really is
a
>request for the portlet being able to control what the Consumer does
as a
>result of End-User interactions with controls the Consumer has inserted
>into the aggregated page, then I would say it falls into areas we
>explicitly excluded from consideration for v1.
>
>
Is the latter for the specific case of Help.
>2. Displaying Help in a separate window or IFrame.
> We have talked more than once about how
a Consumer can manage
>multiple views onto a Portlet (each with its own navigationalState,
>windowState and mode). For a Consumer to launch a new window when the
>End-User presses the Consumer's 'help' control and to access the same
>Portlet from this new window is straight forward. The important key
here
>is for the Portlet to not store information such as mode in a session-like
>manner, but to use what is supplied on each invocation.
>
It is not only the session but also the navigational state. Being a new
window, the new window will have its own navigational state, thus you
can not use session nor nav-state to share information with the Help
running in a separate window..
> An area this does not deal with is the
Portlet being able to cause
>a new view (window or IFrame) to be opened in a different
>windowState/mode. I think there was some speculation about how this
could
>be done in JavaScript at one point, but it certainly has not been fully
>explored (in particular, what are the additional requirements it places
on
>the Consumer?). Is there a strong use case requiring this to be explored
>before v1 is standardized?
>
>
If the consumer uses javascript to do the popup it is up to the
consumer, no need to standardize that.
>Clearly I am concerned about scope-creep here. There are issues here
that
>will need to be addressed, but I think we have the basics covered in
the
>current draft.
>
>Rich Thompson
>
>
>
>
>Alejandro Abdelnur <>
>03/17/2003 06:42 PM
>
> To:
> cc:
> Subject: Handling
HELP
>
>
>My original intention was to wait until this issue is resolved in JSR168
>EG and then bring the outcome for the consideration of WSRP TC. Because
>WSRP is about to stop receiving change requests and I believe it is
>something that WSRP should also address, I'm bringing it now.
>
>IMO, the current state of the specification does not address a common
>use case for handling Help: help being provided by an external system,
>using static pages or displaying Help content at the same time the
user
>is trying to do a task (while the portlet is in VIEW or EDIT mode).
>Following is a list of requirements that would address this use case.
>
>Requirements:
>
>1. It must be possible for Help to be rendered directly by external
>pages (JSP, static HTML, etc).
>2. It must be possible for a portlet to use an external Help system.
>3. It must be possible to display Help side to side with the operation
>the portlet is performing. This has to be done without breaking the
>portlet window semantics (a portlet window can have a single state).
>4. It must be possible to fulfill the previous requirements using the
>Help button in the portlet window decoration.
>5. How this is done it must be simple for portlet developers.
>
>A few clarifications:
>
>Portlet Window is the visual representation of portlet in a portal
page.
>The portlet window decoration would be the title bar of the visual
>representation that normally has a set of buttons to control the portlet
>(EDIT, HELP, MIN, MAX, etc).
>Requirement #3 it could be the case of a popup window or an iframe
>within the portal page that shows the help while the portlet is being
>displayed in VIEW or EDIT. The portlet window semantics sentence refers
>to the fact that a portlet has a single
>portlet-mode/window-state/navigational-state at any given time.
>
>Alejandro
>
>
>
>
>
>
>
>
