[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 <email@example.com> >03/17/2003 11:58 AM > > To: wsrp-wsia <firstname.lastname@example.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:email@example.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:firstname.lastname@example.org > > >|---------+----------------------------> >| | Alejandro | >| | Abdelnur | >| | <alejandro.abdeln| >| | email@example.com> | >| | | >| | 03/14/2003 02:38 | >| | AM | >|---------+----------------------------> > > >--------------------------------------------------------------------------- > >-----------------------------------------------------------------------| > | >| > | To: >| > | cc: wsrp-wsia <firstname.lastname@example.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]