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


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

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


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