Re: Handling HELP

[Rich Thompson <richt2@us.ibm.com>]

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.

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. 
        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? 

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 <alejandro.abdelnur@sun.com>
03/17/2003 06:42 PM
 
        To:     wsrp@lists.oasis-open.org
        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