[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"]
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. Well said. I agree with you. I would like to add the following: - It is fairly easy to come up with portlets that don't rely on modes for any structure/flow, or use some other mechanism for managing structure/flow. - Not all applications share the same sense of what terms like APPLY, OK, CANCEL mean. Regards, Subbu > 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. > > Eilon > > -----Original Message----- > From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] > Sent: Thursday, March 20, 2003 11:34 > To: WSRP > 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 > 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]