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

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.

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 
>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 
>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 
>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"
>     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 
>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.
>-----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 
>a set of CSS classes with common buttons defined as we already discussed. 
>need to figure out this set of buttons. Folks with CSS knowledge should 
>to bring up a proposal here. Maybe Yossi's example is a good starting 
>It would be also nice to have the button labels localized, but need to 
>sure that these is consistent with the markup generated (i.e. english 
>-> 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 
>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 
>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 
>depending on the input of the first page. Therefor I wouldn't consider 
>part as a "must address" in the 1.0 timeframe. The DONE behaviour you
>described could always be coded by the portlet. And I agree there might be
>different flavours how portlet application handle this, but...
>Concerning your proposal in MUST requirements, look and feel section 2: Do
>you propose that the portal should provide the buttons (which, number of
>them etc.)? I think the only one knows its semantics is the portlet 
>so the portlet should request the portal to render the buttons it requests
>(using CSS).
>Mit freundlichen Gruessen / best regards,
>        Richard Jacob 
>IBM Lab Boeblingen, Germany
>Dept.8288, WebSphere Portal Server Development
>Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
>Email: mailto:richard.jacob@de.ibm.com
>|         |           Alejandro        |
>|         |           Abdelnur         |
>|         |           <alejandro.abdeln|
>|         |           ur@sun.com>      |
>|         |                            |
>|         |           03/14/2003 02:38 |
>|         |           AM               |
>  |
>  |       To:
>  |       cc:       wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
>  |       Subject:  Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and
>Some questions/comments embedded.
>Michael Freedman wrote:
>      Folks,
>          A long time ago we decided that the portlet would be responsible
>      for rendering/managing the buttons commonly displayed in modal 
>      For example the portlet renders the "APPLY", "OK", "CANCEL" What do
>you mean by modal MODEs?
>      button in Edit Mode.  Likewise the portlet renders the "DONE" button
>      in Help mode.  Unfortunately, our specification doesn't define how a
>      portlet can accomplish this in ways that meet [what I consider] 
>      requirements.  Namely, the specification doesn't define a uniform 
>      for portlets to recognize what Mode the portlet should return to 
>      "OK", "CANCEL", or "DONE" are invoked.  Also the specification
>      doesn't define a uniform way for portlets to use controls/labels 
>      are consistent with the portal/consumer they are running in.  I feel
>      we must address these deficiencies in 1.0.
>           These are the basic requirements I believe we must meet:
>            Requirements related to managing navigation:
>            MUST requirements:
>            1) The specification must describe/define a single mechanism
>            that allows
>            any portlet [session-based or otherwise] to implement "Done"
>            semantics.
>            "Done" semantics are the ability to optionally accept/process
>            inputed data in a
>            mode other then VIEW and then to exit that mode; Why going 
>to VIEW/NORMAL would not be enough for the DONE semantics? Wouldn't this
>cover most (if not all) cases?
>When you say "inputed data in a mode other than VIEW" I assume you refer 
>modifying properties in EDIT or the DONE woud be used also when the 
>is doing a trasaction in VIEW?
>            generally by returning to the mode from whence the portlet
>            came.
>If a portlet mode transition is VIEW, EDIT, HELP, EDIT, where the DONE
>semantics would take me, back to HELP or to VIEW?
>            2) For portlets using the mechanism defined in (1), the portal
>            MUST be
>            able to establish a uniform navigational look and feel. I.e.
>            users expect portlets in a given consumer to navigate in a
>            consistent manner.
>I assume that by "uniform navigational look and feel" you are meaning
>"uniform navigational behavior", right? I don't know how this could be 
>as the portal has no way to enforce portlets to provide the set of buttons
>that should be displayed in the portlet content. We could certainly make
>recommendations, but to me this belongs to a best practices document.
>            3) The mechanism defined in (1) must allow allow a return to
>            modes other
>            then VIEW. For example, it must be possible for a portal to
>            indicate that a portlet that navigates from VIEW to EDIT to
>            HELP will navigate back to EDIT [not VIEW] when the user is
>            done with HELP mode.
>This is implicitly requiring the consumer to keep a history trace per
>portlet. A portlet can keep track of where to go back in the session or in
>the navigational state. The latter would not work when the user is 
>on the controls (VIEW, EDIT, HELP, NORMAL, MINIMIZE, MAXIMIZE) in the
>portlet window title bar, we have to see how (or if) we fix this.
>            4) The mechansim defined in (1) must work for all non-VIEW
>            modes be they custom or defined by the specification.
>            SHOULD requirements:
>            1) The mechanism defined in (1) SHOULD be expressed in our
>            protocol in an
>            easy and obvious mannner so portlet developers find it
>            convenient.
>I don't see convenient the fact that a portlet will always have to check 
>portletmode and windowstate it will be taken when DONE semantics is 
>What I'm trying to say is, portlets may decide to set different 
>state depending on the portletmode and windowstate they are going. As now 
>is not the portlet the one deciding the portletmode or windowstate, the
>portlet has to check where the portal will take it and then set the proper
>navigation state. IMO, this is an unnecessary complexity forced uppon the
>            2) A portlet SHOULD be able to ignore the mechanism defined by
>            (1) and
>            implement semantics of its choosing [limited by other
>            constraints
>            imposed by the portal/container within the bounds of the
>            specification].  I.e. though we encourage portlets to code
>            themselves using the proscribed technique, portlets should be
>            able to do otherwise at a loss of user interface consistency. 
>wouldn't say this is a SHOULD requirement, portlets can always do this by
>just going to a specific portletmode and windowstate.
>            Requirements related to the look/feel of the buttons
>            MUST requirements:
>            1) The mechanism we define for rendering mode control buttons
>            MUST allow the portal to maintain a uniform look and feel for
>            these controls across all portlets it manages.
>Yes, I think is a good idea to define CSS classes to be used for buttons
>that confirm a task or cancel a task. We could also add (I think it was
>proposed in another change request), next-step and previous-step.
>            2) The mechanism we define for rendering mode control buttons
>            MUST allow the portal to control the number of buttons/types 
>            operations to be used in a given Mode.  I.e. we mustn't 
>            EDIT mode have a 'OK', 'APPLY', and 'CANCEL' button.  A portal
>            may have choosen a different combination of these. I don't
>understand why a portal would remove buttons from the portlet content.
>That's dangerous, it could break portlet functionality encoded in those
>actions (as it is not accessible). It would require the portal to parse 
>portlet content to do. Or it would require to pass with the 
>the list of  buttons the portlet can use, but still a portlet could create 
>button not indicated in the markupParamters.
>            3) The mechanism we define for rendering mode control buttons
>            MUST allow the portal to maintain a uniform labeling of these
>            controls [across locales] across all portlets it manages. It
>seems like a good idea but I'm not sure if the practical end result is
>desirable. Suppose a portlet that always creates English content. It is
>invoked by a userAgent that indicates French locale, the portlet in the
>portal page would have all its content in English except for the control
>button labels that would be in French.
>            SHOULD requirements:
>            1) The mechanism defined in (1) SHOULD be expressed in our
>            protocol in an
>            easy and obvious mannner so portlet developers find it
>            convenient.
>Unless I'm missing something, (1) is about adding a set of CSS classes.
>      The navigational issue is reflected in Change Request #141: Add
>      previous window state and mode.  I will request Rich open a new
>      change request for the button/control management.
>      On the navigational issue: [Change Request #141]:
>      I originally introduced this as a JSR related issue as we first
>      re-identified it in the JSR EG.  Unfortunately, we [the JSR EG] is
>      having a hard time deciding which of the possible mechanisms
>      available to us we should use to resolve this issue. As this is an
>      issue that is equally germane to us, I suggest we tackle this head 
>      without waiting for JSR to make further progress.  In the end our
>      resolution will likely help JSR come to a conclusion.  To get
>      started, I suggest we first discuss/approve the requirements our
>      solution should meet.  Once there is agreement on this 1 to N 
>      can be considered for approval based on these requirements.  To get
>      the ball rolling, I will send out another e-mail with 2 distinct
>      solutions that meet the above requirements.
>      On the button look/feel issue:
>      I seem to recall we proposed this would/could be solved using CSS.
>      Unfortuantely, I am not versed well enough in CSS to propose a
>      solution.  Should we get started by discussing/approving a set or
>      requirements and then pass these on to the Markup subcommittee [or 
>      individual volunteer] to make proposal(s)?
>           -Mike-
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>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] | [List Home]