Alejandro,
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
described)?
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
screen).
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... :-)
Regards,
Eilon
-----Original Message-----
From: Alejandro Abdelnur [mailto:]
Sent: Tuesday, March 18, 2003 01:43
To:
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
