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

Comments embedded


Eilon Reshef wrote:

>I completely agree with this requirement. 
>I do have a couple of comments though:
>1. Do you feel that the spec currently doesn't allow such behavior (as you
No it doesn't if you want the Help button on the portlet title bar to 
trigger the help.

>2. I would like to re-iterate a concern regarding bringing up additional
>application/functional requirements. There are many requirements regarding
>what a portlet should be able to do, including:
>A. Displaying "help".
>B. Validating user input.
>C. Displaying fields of different types and lengths.
>D. Allowing users to save, undo and apply changes.
>...and so on.
>My concern that analyzing each one in depth is not very practical. To some
>degree, there are many types of application and even real requirements that
>are not addressed or addressed poorly by Web-based (thin client)
>infrastructure (e.g., the ability to update the data without refreshing the
>At some point, however, we have to revert to the statement that since a
>portlet can include any functionality available in a multi-step Web-based
>application, then relevant application behavior is likely to be supported.
>If we identify technical areas where we have failed (e.g., maybe we don't
>support IFrames or popups well), then we need to resolve them.
>Getting an agreement, however, on what constitutes a "good" application in
>terms of functionality, user flow, etc. and trying to incorporate that into
>the spec may be beyond the scope of 1.0 (and my hypothesis is that HTTP
>would also not have approved based on such criteria as well... :-)
The difference is that B, C and D can be done with an application 
framework built on top of the WSRP protocol. A, with the requirements 
I've sent, can only be built using WSRP extensions.

>-----Original Message-----
>From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com] 
>Sent: Tuesday, March 18, 2003 01:43
>To: wsrp@lists.oasis-open.org
>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]