[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
>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
>itself,
>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
>"DONE"
>|
>
>
>---------------------------------------------------------------------------
>
>-----------------------------------------------------------------------|
>
>
>
>
>
>Some questions/comments embedded.
>
>Alejandro
>
>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
>MODEs.
> 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]
>basic
> requirements. Namely, the specification doesn't define a uniform
>way
> for portlets to recognize what Mode the portlet should return to
>when
> "OK", "CANCEL", or "DONE" are invoked. Also the specification
> doesn't define a uniform way for portlets to use controls/labels
>that
> 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
>back
>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
>to
>modifying properties in EDIT or the DONE woud be used also when the
>portlet
>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
>done
>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
>clicking
>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
>the
>portletmode and windowstate it will be taken when DONE semantics is
>applied.
>What I'm trying to say is, portlets may decide to set different
>navigational
>state depending on the portletmode and windowstate they are going. As now
>it
>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
>developer.
> 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.
>I
>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
>of
> operations to be used in a given Mode. I.e. we mustn't
>require
> 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
>the
>portlet content to do. Or it would require to pass with the
>markupParameters
>the list of buttons the portlet can use, but still a portlet could create
>a
>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
>on
> 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
>options
> 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
>an
> 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]