Re: [wsrp] Re: Handling HELP

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

>

>

>

>

>

>

>  

>