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: Handling HELP

Comments embedded.


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

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