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", "CAN CEL" and "DONE"]

I think it's also pretty clear that the entire concept of "modes" is a poor
man's way to try to put structure to applications (=portlets). As portlets
become more complex (=have more business value), the distinction between
help, view and edit blurs (e.g., context sensitive help, multiple levels of
customization, remembering the last user state, etc.), and hence this
structure loses much of its value.

Thus, I am also of the opinion that rather than trying to squeeze in more
heuristics around behavior of pre-named buttons, we defer this to a larger
topic in subsequent versions of the protocol.


-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] 
Sent: Thursday, March 20, 2003 11:34
Subject: RE: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN
CEL" 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]