OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp-wsia][#82] What is the need of previousMode?

Option 3: The consumer keeps track of a "default" mode for each portlet
(e.g., the View mode). Instead of supporting a true "back mode", the
"cancel" button links the user back to whatever the portal decides is
the default mode. (We add an additional mode called "default" which can
be returned by the portlet.). This default mode can be stored
persistently per user, per portlet, or whatever. This allows us to
sidestep many of the questions: how is the "back" mode stored, how long
is it being stored (multi-page, logout, ...), how many "back"s are
supported (browser "back" saves the entire history), etc.

-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com] 
Sent: Wednesday, September 25, 2002 9:40 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia][#82] What is the need of previousMode?

I would like to open the discussion on item #82 in the issues list: What
is the need of previousMode?

A remote entity is requested to render its content in a specific mode,
e.g. the edit mode. It wants to embed a link in its markup that sends it
out of the current mode in the previous mode, like e.g. a cancel button
in the edit mode. The entity cannot hardcode the new destination mode as
the desired behaviour would be to go back to the mode that was active
before the switch to edit mode. The entity cannot remember the previous
mode itself because the mode is consumer side information.

I could imagine two options to enable such a behaviour.

The consumer sends the last mode before a mode switch with each request
to the entity (as it does now in the spec). The entity can then use this
mode to encode "exit-from-this-mode" links. If there was no previous
mode the consumer sends the VIEW mode as a default.

In addition to existing modes (VIEW, EDIT, etc) we define a BACK mode as
a predefined constant. The consumer would never use this constant as a
mode to be passed to the entity during rendering. However the entity
could use this constant to encode links that should switch the mode to
the last mode in the change history. The consumer would be required to
keep such a history or default to VIEW mode if either there is no
history available or there is no previous mode.

Best regards

Entry from the issues list:

82    Unassigned  interface   Minor Technical   Sasha Aickin
What is the need of previousMode?
                              Date Added: 10-Sep-2002
                              Document Section: Interfaces/6.1
                              Description:      I share Alejandro's
question about the previousMode argument to getMarkup.  Also, what does
previousMode mean exactly?  If for example the user last logged in a
week ago, is the portal expected to remember the modes of every entity?
Is the mode tracking keyed on a portal/portlet/entity basis (and thus
shared among many users), a portal/portlet/entity/user basis (and thus
shared among one user's several sessions) or on a
portal/portlet/entity/user/session basis? In my mind, this argument
seems like unnecessary complexity without a clear use case.

Best regards
Carsten Leue

Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC