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 we are buying unnecessary trouble if we defer this entire 
issue. I don't like drilling down into details on the particulars of 
buttons and naming conventions, but I don't see a way around it. This 
is another case of either inviting a myriad of hard-to-replace 
practices or setting the least number of options at the highest level 
possible. I think confining ourselves to current and previous user 
navigational states for window and mode, with OK, CANCEL AND APPLY 
seems like the least we need to do to prevent a quagmire of practices 
to sort out for v1.1-2.


At 2:27 PM +0200 3/20/03, Eilon Reshef wrote:
>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

Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com

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