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: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"]

I agree, I would rather have multiple (application dependent) look and feels
and associated navigational behaviours rather than one l&f with diverse

The JSR168 has been discussing various incomplete solutions to the larger
problem of navigation and I would like to step back and consider a more
abstract solution that lets either the portal or the portlet implement

So far, I have been trying to work though the requirements and issues in the
JSR 168 and would like to try for a fuller proposal when we have a chance to
fully consider these related issues.


-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 20 March 2003 02:43
Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK",
"CANCEL" and "DONE"]

Are you suggesting that this spec define or standardize what
APPLY/OK/CANCEL/DONE means? We should try something more abstract.


Michael Freedman wrote:
> -------- Original Message --------
> Return-Path: <Michael.Freedman@oracle.com>
> Received: from rgmgw4.us.oracle.com (localhost []) by 
> rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id 
> h2JJJ9B08607 for <Michael.Freedman@oracle.com>; Wed, 19 Mar 2003 
> 12:19:09 -0700 (MST)
> Received: from oracle.com (mfreedma-pc2.us.oracle.com []) 
> by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id 
> h2JJJ8o08552; Wed, 19 Mar 2003 12:19:08 -0700 (MST)
> Message-ID: <3E78C1D6.7030406@oracle.com>
> Date: Wed, 19 Mar 2003 11:15:34 -0800
> From: Michael Freedman <Michael.Freedman@oracle.com>
> Organization: Oracle Corporation
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) 
> Gecko/20021120 Netscape/7.01
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: Rich Thompson <richt2@us.ibm.com>
> Subject: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and 
> "DONE"
> References: 
> <OF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com>
> Content-Type: multipart/alternative; 
> boundary="------------070303070803040100090707"
> 'OK' means 'Apply' [the changes] and exit this mode.  'Apply' means 
> apply the changes but stay in this mode.      -Mike-
> Rich Thompson wrote:
>> I thought about this as well as we have done similar in past projects. 
>> The difficulty is that the Consumer now has to rewrite a significant 
>> part of the portlet's content in a way that still carries the 
>> semantics intended for each control (also, this starts to head down 
>> the path of the Consumer transforming a portion of the markup while 
>> not requiring any particular technology for doing so). The Portlet no 
>> longer knows what controls will exist on the page and therefore has to 
>> write reasonable semantics for each possibility. These are not 
>> difficult things to overcome, but would involve a change in the 
>> abstractness of what the Portlet write as markup. I think v1 should 
>> stick at the simpler concrete level of defining individual classes and 
>> possibly revisit adding more abstract concepts in v2.
>> Your comments suggest also adding a "wsrp-ok" class. What would be the 
>> semantics of the control (distinct from wsrp-apply)?
>> Rich Thompson
>> Michael Freedman <Michael.Freedman@oracle.com>
>> 03/19/2003 01:27 PM
>>                To:        WSRP <wsrp@lists.oasis-open.org>, 
>> wsrp-wsia@lists.oasis-open.org
>>         cc:                Subject:        [wsrp] Re: [wsrp-wsia] 
>> Handling "APPLY", "OK", "CANCEL" and "DONE"
>> Rich,
>> Sounds good.  I wonder if we can get even simpler on the look side of
>> things and merely define a style called wsrp-edit-controls and
>> wsrp-help-controls.  The wsrp-edit-controls style would let the portlet
>> set a apply, cancel, and ok URL.  The wsrp-help-controls would merely
>> let the portlet set a done URL.  The advantage I see in this over your
>> proposal to offer a style per button type is that the consumer can now
>> control whioch of these buttons they actually want to display.  I.e. One
>> consumer/portal might choose to only have "OK" and "Cancel"  while
>> another also includes the "Apply". 
>> Note: we could even consider getting away with the most minimal solution
>> that provides only a single style:
>> wsrp-mode-control.  With this style the producer always sets the apply,
>> cancel, and ok URLs.  The consumer exposes buttons/chooses URLs absed on
>> what makes sense for the mode.  For example a consumer might choose to
>> only expose a "Done" button in help mode and map the cancel [or OK] URL
>> to it.
>>      -Mike-
>> Rich Thompson wrote:
>> >I think the biggest question is how to draw the line so that we don't 
>> have
>> >too much of an issue with the slippery slope character of this area. We
>> >certainly do not want to be defining a metadata language for Consumer to
>> >declare their control navigational semantics. Nor do we want to 
>> require a
>> >particular means for Consumers to do some sort of match and transform 
>> on a
>> >Portlet's markup (e.g. XSLT as a means to find/replace control
>> >specification).
>> >
>> >What I think has been proposed is the Consumer supplying information so
>> >that the Portlet can write navigational semantics that will have some
>> >consistency with other Portlets on the same page. The only candidates 
>> for
>> >additional information of this type that have been raised are 
>> previousMode
>> >and previousWindowState. If these were provided and used by Portlets to
>> >navigate back, then however the Consumer chooses to set these values
>> >becomes the level of consistency across its pages.
>> >
>> >On the 'Look' side of the house, I think the key is keeping the set of
>> >additional classes relatively small. Here is a suggestion:
>> >  wsrp-cancel: Semantics = abort the current end-user activity.
>> >  wsrp-apply: Semantics = accept and apply the current end-user 
>> activity.
>> >  wsrp-previous: Semantics = navigate to previous page in the current
>> >end-user activity
>> >  wsrp-next: Semantics = navigate to the next page in the current 
>> end-user
>> >activity
>> >
>> >I would suggest we not deal with making a cross product of these with 
>> user
>> >interaction (e.g. hover, selected, down, etc.) for v1 as this opens 
>> issues
>> >related to how many such modifiers and how does the class name get
>> >changed.
>> >
>> >Rich Thompson
>> >
>> >
>> >
>> >
>> >Michael Freedman <michael.freedman@oracle.com>
>> >03/17/2003 11:58 AM
>> >
>> >        To:     wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
>> >        cc:
>> >        Subject:        Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL"
>> >and "DONE"
>> >
>> >
>> >Folks,
>> >     I wonder if I have created some confusion.  I am not suggesting 
>> that
>> >we either define control L/F or navigational semantics that provides
>> >uniformity accross consumers.  I am sugesting we define mechanisms so 
>> that
>> >portlet which desire to play by the rules can conveniently implement the
>> >consumers control L/F and navigational semantics.  I.e. we need ways in
>> >which portlet developers can get at this information/express it.  We 
>> don't
>> >need to define a common semantic between portals.
>> >
>> >On control L/F I am hoping we can get anway with something simple -- 
>> Is it
>> >possible to define a CSS which represents the "APPLY, "OK", "CANCEL"
>> >buttons as a single set?  In this CSS a developer would merely set the
>> >APPLY url, OK url, and Cancel url.  The CSS class would take care of
>> >ordering these, naming these, and potentially even excluding unneeded
>> >ones.  If such a thing is doable then we could consider only doing 
>> the one
>> >or providng a separate CSS class for situations where a single button
>> >"DONE/Cancel/back" would be suitable.  Again, in this CSS the developer
>> >would only provide the URL.  The CSS class would define the rest.
>> >
>> >On the navigational semantics, the problem we have in our protocol today
>> >is that there is no way for a session-less portlet to do anything but
>> >hardcode its navigational semantics.  I believe this is a big 
>> oversight in
>> >our specification -- paticularly when its fairly easy to resolve by 
>> merely
>> >asking the portal to pass information in the request.  Since we require
>> >the portlet to deal with impelmenting portal semantics "OK", 
>> "CANCEL", etc
>> >our protocol should be complete enough so it can do its job. 
>>  Therefore I
>> >don't see how this can wait to 1.1 -- as there is no way a hardcoded
>> >portlet will fit into a future design without rewrite.
>> >      -Mike-
>> >
>> >Eilon Reshef wrote:
>> >I would like to second that. I also think that button behavior falls 
>> under
>> >application semantics and the less we get into those muddy waters the
>> >better
>> >we are, even if some consistency is sacrificed. If people want to 
>> develop
>> >bad applications (=portlets) so be it, and we can always add more 
>> detailed
>> >_guidelines_ in the next version.
>> >
>> >Eilon
>> >
>> >-----Original Message-----
>> >From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
>> >Sent: Monday, March 17, 2003 18:24
>> >To: wsrp-wsia
>> >Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"
>> >
>> >
>> >
>> >I agree that it is desireable to have a common look&feel (and I would 
>> say
>> >it's more the "look" than the "feel"). Therfor I would say we should
>> >define
>> >a set of CSS classes with common buttons defined as we already 
>> discussed.
>> >We
>> >need to figure out this set of buttons. Folks with CSS knowledge should
>> >try
>> >to bring up a proposal here. Maybe Yossi's example is a good starting
>> >point.
>> >It would be also nice to have the button labels localized, but need to
>> >make
>> >sure that these is consistent with the markup generated (i.e. english
>> >markup
>> >-> english buttons). Also we need to define a fallback behaviour if 
>> markup
>> >and buttons locales do not overlap. Also overrides for default text 
>> should
>> >be possible?
>> >
>> >However I'm not sure about the common navigational semantics. In an 
>> ideal
>> >world all UIs would behave consistently. But I think it is pretty 
>> hard to
>> >agree on a common behaviour, i.e. semantic definitions for each such
>> >button
>> >which satisfies the whole bunch of possible applications. That's why JSR
>> >folks a having a hard time on this, as far as I understood. If you 
>> look at
>> >UI's like Windows or KDE, etc. They provide the user with a common look
>> >but
>> >every application is free to decide on the semantics on button-actions
>> >(close dialog, display information, etc.) We don't really know what
>> >applications want to code, right? For example a portlet may have 
>> different
>> >setup pages in EDIT mode and a "OK" button leads the user back to 
>> page one
>> >of EDIT mode for instance - a mode change to "VIEW" wouldn't be the
>> >behaviour the portlet wants. Or assume a wizard like dialog in EDIT 
>> mode,
>> >where one OK on one page triggers the portlet to enter yet another EDIT
>> >page
>> >depending on the input of the first page. Therefor I wouldn't consider
>> >this

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