Re: [wsrp] Re: Handling HELP

[Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>]

Title:

If nobody else sees this as an issue that should be addressed for v1
I'll have to leave with an extension for now.

Alejandro

Rich Thompson wrote:

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 <alejandro.abdelnur@sun.com> 03/18/2003 04:40 PM

To:                 cc:        wsrp@lists.oasis-open.org         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 <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
>
>
>
>
>
>
>  
>