[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", "CANCEL" 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 behaviours. 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 history. 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. regards, Andre -----Original Message----- From: Subbu Allamaraju [mailto:subbu@bea.com] Sent: 20 March 2003 02:43 To: WSRP 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. Subbu Michael Freedman wrote: > > > -------- Original Message -------- > Return-Path: <Michael.Freedman@oracle.com> > Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) 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 [130.35.93.129]) > 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]