[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsrp] mailing list usage
Dear members, as you already might have heard the new kavi system on OASIS will be launched soon. The OASIS TC chairs and secretaries worked together to set up the new plattform. The way the system is set up is the following: There is one TC member roster which gives people access to documents and the wsrp mailinglist. This is the official entry point to wsrp documents/mailing list, etc. For each subgroup we have set up a subcommitee with the appropriate mailing lists, rosters and chairs. Each subgroup has its own roster (that's how things work within kavi). Currently the wsrp-wsia mailinglist is setup as the WSRP/WSIA subcommittee mailing list. This however brings us organisational overhead as we have to maintain the WSRP TC roster and the WSRP/WSIA SC roster. Generally both rosters are/should be in synch as all TC members are also SC members and post to the wsrp-wsia mailinglist. WSIA members are are set up as non-voting WSRP TC members and therefor have access here also. The wsrp list which is considered our official WSRP TC mailing is never used, however. Is there any argument why we use the wsrp-wsia list instead of the wsrp list except of the "political statement" that this is a joint effort? (And I understand the importance of this statement, but meanwhile it should be clear that this is a joint spec). Why do we have both lists? I think this has historical reasons only. To reduce administrative overhead I would like to propose the following: - use the wsrp mailing list as the official TC mailing list, post messages concerning the spec to this list. - do not use wsrp-wsia any more for the spec postings - use the wsrp-wsia SC for "real" WSRP/WSIA joint interfaces SC topics which might come up in future, or drop the subcommittee. This would also make it clearer for people where to subscribe. BTW checking the subscriptions for both lists in turns out that there are about 140 people subscribed to the wsrp list, while ~80 people are subscribed to the wsrp-wsia list. I would assume that people subscribed to wsrp-wsia are also subscribed to wsrp. 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> Received: (qmail 7385 invoked by uid 60881); 19 Mar 2003 22:41:35 -0000 Received: from Michael.Freedman@oracle.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-4.5/8.0):. Processed in 1.888081 secs); 19 Mar 2003 22:41:35 -0000 X-Spam-Status: No, hits=-4.5 required=8.0 Received: from unknown (HELO inet-mail2.oracle.com) (148.87.2.202) by mail.oasis-open.org with SMTP; 19 Mar 2003 22:41:33 -0000 Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2JMnG721067 for <wsrp@lists.oasis-open.org>; Wed, 19 Mar 2003 14:49:16 -0800 (PST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail2.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JMnFo21047 for <wsrp@lists.oasis-open.org>; Wed, 19 Mar 2003 14:49:16 -0800 (PST) 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 h2JMnEB14622 for <wsrp@lists.oasis-open.org>; Wed, 19 Mar 2003 15:49:14 -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 h2JMnBo14539; Wed, 19 Mar 2003 15:49:11 -0700 (MST) Message-ID: <3E78F310.9000807@oracle.com> Date: Wed, 19 Mar 2003 14:45:36 -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: WSRP <wsrp@lists.oasis-open.org> Subject: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"] Content-Type: multipart/alternative; boundary="------------030703080108070502040308" --------------030703080108070502040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- 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 > >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> > > > > > > > --------------030703080108070502040308 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> <br> <br> -------- Original Message -------- <table cellpadding="0" cellspacing="0" border="0"> <tbody> <tr> <th valign="baseline" align="right" nowrap="nowrap">Return-Path: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:Michael.Freedman@oracle.com"><Michael.Freedman@oracle.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>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 <a class="moz-txt-link-rfc2396E" href="mailto:Michael.Freedman@oracle.com"><Michael.Freedman@oracle.com></a>; Wed, 19 Mar 2003 12:19:09 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>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)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Message-ID: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:3E78C1D6.7030406@oracle.com"><3E78C1D6.7030406@oracle.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Date: </th> <td>Wed, 19 Mar 2003 11:15:34 -0800</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">From: </th> <td>Michael Freedman <a class="moz-txt-link-rfc2396E" href="mailto:Michael.Freedman@oracle.com"><Michael.Freedman@oracle.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Organization: </th> <td>Oracle Corporation</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">User-Agent: </th> <td>Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">X-Accept-Language: </th> <td>en-us, en</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">MIME-Version: </th> <td>1.0</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">To: </th> <td>Rich Thompson <a class="moz-txt-link-rfc2396E" href="mailto:richt2@us.ibm.com"><richt2@us.ibm.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Subject: </th> <td>Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">References: </th> <td><a class="moz-txt-link-rfc2396E" href="OF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com">mailto:OF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com"><OF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Content-Type: </th> <td>multipart/alternative; boundary="------------070303070803040100090707"</td> </tr> </tbody> </table> <br> <br> <title></title> 'OK' means 'Apply' [the changes] and exit this mode. 'Apply' means apply the changes but stay in this mode. <br> -Mike-<br> <br> Rich Thompson wrote:<br> <blockquote type="cite" cite="midOF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com"> <br> <font size="2" face="sans-serif">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.</font> <br> <br> <font size="2" face="sans-serif">Your comments suggest also adding a "wsrp-ok" class. What would be the semantics of the control (distinct from wsrp-apply)?</font> <br> <font size="2" face="sans-serif"><br> Rich Thompson</font> <br> <br> <br> <table width="100%"> <tbody> <tr valign="top"> <td> <br> </td> <td><font size="1" face="sans-serif"><b>Michael Freedman <a class="moz-txt-link-rfc2396E" href="mailto:Michael.Freedman@oracle.com"><Michael.Freedman@oracle.com></a></b></font> <p><font size="1" face="sans-serif">03/19/2003 01:27 PM</font> </p> </td> <td><font size="1" face="Arial"> </font> <br> <font size="1" face="sans-serif"> To: WSRP <a class="moz-txt-link-rfc2396E" href="mailto:wsrp@lists.oasis-open.org"><wsrp@lists.oasis-open.org></a>, <a class="moz-txt-link-abbreviated" href="mailto:wsrp-wsia@lists.oasis-open.org">wsrp-wsia@lists.oasis-open.org</a></font> <br> <font size="1" face="sans-serif"> cc: </font> <br> <font size="1" face="sans-serif"> Subject: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"</font></td> </tr> </tbody> </table> <br> <br> <br> <font size="2"><tt>Rich,<br> Sounds good. I wonder if we can get even simpler on the look side of <br> things and merely define a style called wsrp-edit-controls and <br> wsrp-help-controls. The wsrp-edit-controls style would let the portlet <br> set a apply, cancel, and ok URL. The wsrp-help-controls would merely <br> let the portlet set a done URL. The advantage I see in this over your <br> proposal to offer a style per button type is that the consumer can now <br> control whioch of these buttons they actually want to display. I.e. One <br> consumer/portal might choose to only have "OK" and "Cancel" while <br> another also includes the "Apply". <br> <br> Note: we could even consider getting away with the most minimal solution <br> that provides only a single style:<br> wsrp-mode-control. With this style the producer always sets the apply, <br> cancel, and ok URLs. The consumer exposes buttons/chooses URLs absed on <br> what makes sense for the mode. For example a consumer might choose to <br> only expose a "Done" button in help mode and map the cancel [or OK] URL <br> to it.<br> -Mike-<br> <br> <br> Rich Thompson wrote:<br> <br> >I think the biggest question is how to draw the line so that we don't have <br> >too much of an issue with the slippery slope character of this area. We <br> >certainly do not want to be defining a metadata language for Consumer to <br> >declare their control navigational semantics. Nor do we want to require a <br> >particular means for Consumers to do some sort of match and transform on a <br> >Portlet's markup (e.g. XSLT as a means to find/replace control <br> >specification).<br> ><br> >What I think has been proposed is the Consumer supplying information so <br> >that the Portlet can write navigational semantics that will have some <br> >consistency with other Portlets on the same page. The only candidates for <br> >additional information of this type that have been raised are previousMode <br> >and previousWindowState. If these were provided and used by Portlets to <br> >navigate back, then however the Consumer chooses to set these values <br> >becomes the level of consistency across its pages.<br> ><br> >On the 'Look' side of the house, I think the key is keeping the set of <br> >additional classes relatively small. Here is a suggestion:<br> > wsrp-cancel: Semantics = abort the current end-user activity.<br> > wsrp-apply: Semantics = accept and apply the current end-user activity.<br> > wsrp-previous: Semantics = navigate to previous page in the current <br> >end-user activity<br> > wsrp-next: Semantics = navigate to the next page in the current end-user <br> >activity<br> ><br> >I would suggest we not deal with making a cross product of these with user <br> >interaction (e.g. hover, selected, down, etc.) for v1 as this opens issues <br> >related to how many such modifiers and how does the class name get <br> >changed.<br> ><br> >Rich Thompson<br> ><br> ><br> ><br> ><br> >Michael Freedman <a class="moz-txt-link-rfc2396E" href="mailto:michael.freedman@oracle.com"><michael.freedman@oracle.com></a><br> >03/17/2003 11:58 AM<br> > <br> > To: wsrp-wsia <a class="moz-txt-link-rfc2396E" href="mailto:wsrp-wsia@lists.oasis-open.org"><wsrp-wsia@lists.oasis-open.org></a><br> > cc: <br> > Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" <br> >and "DONE"<br> ><br> ><br> >Folks,<br> > I wonder if I have created some confusion. I am not suggesting that <br> >we either define control L/F or navigational semantics that provides <br> >uniformity accross consumers. I am sugesting we define mechanisms so that <br> >portlet which desire to play by the rules can conveniently implement the <br> >consumers control L/F and navigational semantics. I.e. we need ways in <br> >which portlet developers can get at this information/express it. We don't <br> >need to define a common semantic between portals.<br> ><br> >On control L/F I am hoping we can get anway with something simple -- Is it <br> >possible to define a CSS which represents the "APPLY, "OK", "CANCEL" <br> >buttons as a single set? In this CSS a developer would merely set the <br> >APPLY url, OK url, and Cancel url. The CSS class would take care of <br> >ordering these, naming these, and potentially even excluding unneeded <br> >ones. If such a thing is doable then we could consider only doing the one <br> >or providng a separate CSS class for situations where a single button <br> >"DONE/Cancel/back" would be suitable. Again, in this CSS the developer <br> >would only provide the URL. The CSS class would define the rest.<br> ><br> >On the navigational semantics, the problem we have in our protocol today <br> >is that there is no way for a session-less portlet to do anything but <br> >hardcode its navigational semantics. I believe this is a big oversight in <br> >our specification -- paticularly when its fairly easy to resolve by merely <br> >asking the portal to pass information in the request. Since we require <br> >the portlet to deal with impelmenting portal semantics "OK", "CANCEL", etc <br> >our protocol should be complete enough so it can do its job. Therefore I <br> >don't see how this can wait to 1.1 -- as there is no way a hardcoded <br> >portlet will fit into a future design without rewrite.<br> > -Mike-<br> ><br> >Eilon Reshef wrote:<br> >I would like to second that. I also think that button behavior falls under<br> >application semantics and the less we get into those muddy waters the <br> >better<br> >we are, even if some consistency is sacrificed. If people want to develop<br> >bad applications (=portlets) so be it, and we can always add more detailed<br> >_guidelines_ in the next version.<br> ><br> >Eilon<br> ><br> >-----Original Message-----<br> >From: Richard Jacob [<a class="moz-txt-link-freetext" href="mailto:richard.jacob@de.ibm.com">mailto:richard.jacob@de.ibm.com</a>] <br> >Sent: Monday, March 17, 2003 18:24<br> >To: wsrp-wsia<br> >Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"<br> ><br> ><br> ><br> >I agree that it is desireable to have a common look&feel (and I would say<br> >it's more the "look" than the "feel"). Therfor I would say we should <br> >define<br> >a set of CSS classes with common buttons defined as we already discussed. <br> >We<br> >need to figure out this set of buttons. Folks with CSS knowledge should <br> >try<br> >to bring up a proposal here. Maybe Yossi's example is a good starting <br> >point.<br> >It would be also nice to have the button labels localized, but need to <br> >make<br> >sure that these is consistent with the markup generated (i.e. english <br> >markup<br> >-> english buttons). Also we need to define a fallback behaviour if markup<br> >and buttons locales do not overlap. Also overrides for default text should<br> >be possible?<br> ><br> >However I'm not sure about the common navigational semantics. In an ideal<br> >world all UIs would behave consistently. But I think it is pretty hard to<br> >agree on a common behaviour, i.e. semantic definitions for each such <br> >button<br> >which satisfies the whole bunch of possible applications. That's why JSR<br> >folks a having a hard time on this, as far as I understood. If you look at<br> >UI's like Windows or KDE, etc. They provide the user with a common look <br> >but<br> >every application is free to decide on the semantics on button-actions<br> >(close dialog, display information, etc.) We don't really know what<br> >applications want to code, right? For example a portlet may have different<br> >setup pages in EDIT mode and a "OK" button leads the user back to page one<br> >of EDIT mode for instance - a mode change to "VIEW" wouldn't be the<br> >behaviour the portlet wants. Or assume a wizard like dialog in EDIT mode,<br> >where one OK on one page triggers the portlet to enter yet another EDIT <br> >page<br> >depending on the input of the first page. Therefor I wouldn't consider <br> >this<br> >part as a "must address" in the 1.0 timeframe. The DONE behaviour you<br> >described could always be coded by the portlet. And I agree there might be<br> >different flavours how portlet application handle this, but...<br> ><br> >Concerning your proposal in MUST requirements, look and feel section 2: Do<br> >you propose that the portal should provide the buttons (which, number of<br> >them etc.)? I think the only one knows its semantics is the portlet <br> >itself,<br> >so the portlet should request the portal to render the buttons it requests<br> >(using CSS).<br> ><br> >Mit freundlichen Gruessen / best regards,<br> ><br> > Richard Jacob <br> >______________________________________________________<br> >IBM Lab Boeblingen, Germany<br> >Dept.8288, WebSphere Portal Server Development<br> >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888<br> >Email: <a class="moz-txt-link-freetext" href="mailto:richard.jacob@de.ibm.com">mailto:richard.jacob@de.ibm.com</a><br> ><br> ><br> >|---------+----------------------------><br> >| | Alejandro |<br> >| | Abdelnur |<br> >| | <alejandro.abdeln|<br> >| | <a class="moz-txt-link-abbreviated" href="mailto:ur@sun.com">ur@sun.com</a>> |<br> >| | |<br> >| | 03/14/2003 02:38 |<br> >| | AM |<br> >|---------+----------------------------><br> > <br> > <br> >---------------------------------------------------------------------------<br> > <br> >-----------------------------------------------------------------------|<br> > |<br> >|<br> > | To:<br> >|<br> > | cc: wsrp-wsia <a class="moz-txt-link-rfc2396E" href="mailto:wsrp-wsia@lists.oasis-open.org"><wsrp-wsia@lists.oasis-open.org></a><br> >|<br> > | Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and<br> >"DONE"<br> >|<br> > <br> > <br> >---------------------------------------------------------------------------<br> > <br> >-----------------------------------------------------------------------|<br> ><br> ><br> ><br> ><br> ><br> >Some questions/comments embedded.<br> ><br> >Alejandro<br> ><br> >Michael Freedman wrote:<br> > Folks,<br> > A long time ago we decided that the portlet would be responsible<br> > for rendering/managing the buttons commonly displayed in modal <br> >MODEs.<br> > For example the portlet renders the "APPLY", "OK", "CANCEL" What do<br> >you mean by modal MODEs?<br> > button in Edit Mode. Likewise the portlet renders the "DONE" button<br> > in Help mode. Unfortunately, our specification doesn't define how a<br> > portlet can accomplish this in ways that meet [what I consider] <br> >basic<br> > requirements. Namely, the specification doesn't define a uniform <br> >way<br> > for portlets to recognize what Mode the portlet should return to <br> >when<br> > "OK", "CANCEL", or "DONE" are invoked. Also the specification<br> > doesn't define a uniform way for portlets to use controls/labels <br> >that<br> > are consistent with the portal/consumer they are running in. I feel<br> > we must address these deficiencies in 1.0.<br> > These are the basic requirements I believe we must meet:<br> > Requirements related to managing navigation:<br> > MUST requirements:<br> > 1) The specification must describe/define a single mechanism<br> > that allows<br> > any portlet [session-based or otherwise] to implement "Done"<br> > semantics.<br> > "Done" semantics are the ability to optionally accept/process<br> > inputed data in a<br> > mode other then VIEW and then to exit that mode; Why going <br> >back<br> >to VIEW/NORMAL would not be enough for the DONE semantics? Wouldn't this<br> >cover most (if not all) cases?<br> ><br> >When you say "inputed data in a mode other than VIEW" I assume you refer <br> >to<br> >modifying properties in EDIT or the DONE woud be used also when the <br> >portlet<br> >is doing a trasaction in VIEW?<br> > generally by returning to the mode from whence the portlet<br> > came.<br> >If a portlet mode transition is VIEW, EDIT, HELP, EDIT, where the DONE<br> >semantics would take me, back to HELP or to VIEW?<br> > 2) For portlets using the mechanism defined in (1), the portal<br> > MUST be<br> > able to establish a uniform navigational look and feel. I.e.<br> > users expect portlets in a given consumer to navigate in a<br> > consistent manner.<br> >I assume that by "uniform navigational look and feel" you are meaning<br> >"uniform navigational behavior", right? I don't know how this could be <br> >done<br> >as the portal has no way to enforce portlets to provide the set of buttons<br> >that should be displayed in the portlet content. We could certainly make<br> >recommendations, but to me this belongs to a best practices document.<br> > 3) The mechanism defined in (1) must allow allow a return to<br> > modes other<br> > then VIEW. For example, it must be possible for a portal to<br> > indicate that a portlet that navigates from VIEW to EDIT to<br> > HELP will navigate back to EDIT [not VIEW] when the user is<br> > done with HELP mode.<br> >This is implicitly requiring the consumer to keep a history trace per<br> >portlet. A portlet can keep track of where to go back in the session or in<br> >the navigational state. The latter would not work when the user is <br> >clicking<br> >on the controls (VIEW, EDIT, HELP, NORMAL, MINIMIZE, MAXIMIZE) in the<br> >portlet window title bar, we have to see how (or if) we fix this.<br> > 4) The mechansim defined in (1) must work for all non-VIEW<br> > modes be they custom or defined by the specification.<br> ><br> > SHOULD requirements:<br> > 1) The mechanism defined in (1) SHOULD be expressed in our<br> > protocol in an<br> > easy and obvious mannner so portlet developers find it<br> > convenient.<br> >I don't see convenient the fact that a portlet will always have to check <br> >the<br> >portletmode and windowstate it will be taken when DONE semantics is <br> >applied.<br> >What I'm trying to say is, portlets may decide to set different <br> >navigational<br> >state depending on the portletmode and windowstate they are going. As now <br> >it<br> >is not the portlet the one deciding the portletmode or windowstate, the<br> >portlet has to check where the portal will take it and then set the proper<br> >navigation state. IMO, this is an unnecessary complexity forced uppon the<br> >developer.<br> > 2) A portlet SHOULD be able to ignore the mechanism defined by<br> > (1) and<br> > implement semantics of its choosing [limited by other<br> > constraints<br> > imposed by the portal/container within the bounds of the<br> > specification]. I.e. though we encourage portlets to code<br> > themselves using the proscribed technique, portlets should be<br> > able to do otherwise at a loss of user interface consistency. <br> >I<br> >wouldn't say this is a SHOULD requirement, portlets can always do this by<br> >just going to a specific portletmode and windowstate.<br> > Requirements related to the look/feel of the buttons<br> > MUST requirements:<br> > 1) The mechanism we define for rendering mode control buttons<br> > MUST allow the portal to maintain a uniform look and feel for<br> > these controls across all portlets it manages.<br> >Yes, I think is a good idea to define CSS classes to be used for buttons<br> >that confirm a task or cancel a task. We could also add (I think it was<br> >proposed in another change request), next-step and previous-step.<br> > 2) The mechanism we define for rendering mode control buttons<br> > MUST allow the portal to control the number of buttons/types <br> >of<br> > operations to be used in a given Mode. I.e. we mustn't <br> >require<br> > EDIT mode have a 'OK', 'APPLY', and 'CANCEL' button. A portal<br> > may have choosen a different combination of these. I don't<br> >understand why a portal would remove buttons from the portlet content.<br> >That's dangerous, it could break portlet functionality encoded in those<br> >actions (as it is not accessible). It would require the portal to parse <br> >the<br> >portlet content to do. Or it would require to pass with the <br> >markupParameters<br> >the list of buttons the portlet can use, but still a portlet could create <br> >a<br> >button not indicated in the markupParamters.<br> > 3) The mechanism we define for rendering mode control buttons<br> > MUST allow the portal to maintain a uniform labeling of these<br> > controls [across locales] across all portlets it manages. It<br> >seems like a good idea but I'm not sure if the practical end result is<br> >desirable. Suppose a portlet that always creates English content. It is<br> >invoked by a userAgent that indicates French locale, the portlet in the<br> >portal page would have all its content in English except for the control<br> >button labels that would be in French.<br> > SHOULD requirements:<br> > 1) The mechanism defined in (1) SHOULD be expressed in our<br> > protocol in an<br> > easy and obvious mannner so portlet developers find it<br> > convenient.<br> >Unless I'm missing something, (1) is about adding a set of CSS classes.<br> > The navigational issue is reflected in Change Request #141: Add<br> > previous window state and mode. I will request Rich open a new<br> > change request for the button/control management.<br> ><br> > On the navigational issue: [Change Request #141]:<br> > I originally introduced this as a JSR related issue as we first<br> > re-identified it in the JSR EG. Unfortunately, we [the JSR EG] is<br> > having a hard time deciding which of the possible mechanisms<br> > available to us we should use to resolve this issue. As this is an<br> > issue that is equally germane to us, I suggest we tackle this head <br> >on<br> > without waiting for JSR to make further progress. In the end our<br> > resolution will likely help JSR come to a conclusion. To get<br> > started, I suggest we first discuss/approve the requirements our<br> > solution should meet. Once there is agreement on this 1 to N <br> >options<br> > can be considered for approval based on these requirements. To get<br> > the ball rolling, I will send out another e-mail with 2 distinct<br> > solutions that meet the above requirements.<br> ><br> > On the button look/feel issue:<br> > I seem to recall we proposed this would/could be solved using CSS.<br> > Unfortuantely, I am not versed well enough in CSS to propose a<br> > solution. Should we get started by discussing/approving a set or<br> > requirements and then pass these on to the Markup subcommittee [or <br> >an<br> > individual volunteer] to make proposal(s)?<br> > -Mike-<br> ><br> ><br> ><br> >----------------------------------------------------------------<br> >To subscribe or unsubscribe from this elist use the subscription<br> >manager: <a class="moz-txt-link-rfc2396E" href="http://lists.oasis-open.org/ob/adm.pl"><http://lists.oasis-open.org/ob/adm.pl></a><br> ><br> >----------------------------------------------------------------<br> >To subscribe or unsubscribe from this elist use the subscription<br> >manager: <a class="moz-txt-link-rfc2396E" href="http://lists.oasis-open.org/ob/adm.pl"><http://lists.oasis-open.org/ob/adm.pl></a><br> > <br> ><br> ><br> ><br> >----------------------------------------------------------------<br> >To subscribe or unsubscribe from this elist use the subscription<br> >manager: <a class="moz-txt-link-rfc2396E" href="http://lists.oasis-open.org/ob/adm.pl"><http://lists.oasis-open.org/ob/adm.pl></a><br> > <br> ><br> <br> <br> </tt></font> <br> </blockquote> <br> </body> </html> --------------030703080108070502040308-- Received: (qmail 3856 invoked by uid 60881); 20 Mar 2003 00:56:40 -0000 Received: from Michael.Freedman@oracle.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-2.1/8.0):. Processed in 1.172456 secs); 20 Mar 2003 00:56:40 -0000 X-Spam-Status: No, hits=-2.1 required=8.0 Received: from unknown (HELO inet-mail3.oracle.com) (148.87.2.203) by mail.oasis-open.org with SMTP; 20 Mar 2003 00:56:39 -0000 Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2K14OE24620; Wed, 19 Mar 2003 17:04:24 -0800 (PST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2K14N824611; Wed, 19 Mar 2003 17:04:24 -0800 (PST) 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 h2K14NB26362; Wed, 19 Mar 2003 18:04:23 -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 h2K14Mo26331; Wed, 19 Mar 2003 18:04:22 -0700 (MST) Message-ID: <3E7912C0.4090802@oracle.com> Date: Wed, 19 Mar 2003 17:00:48 -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: WSRP <wsrp@lists.oasis-open.org>, wsrp-wsia <wsrp-wsia@lists.oasis-open.org> Subject: [Fwd: Supporting 'Back' semantics] Content-Type: multipart/alternative; boundary="------------040707060102080008080108" --------------040707060102080008080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To further motivate why we should allow 'Back' semantics to be passed by the consumer in our protocol I have forwarded an e-mail I sent to the JSR 168 EG providing example code that shows that without such support the portlet developer is forced to invent/write their own getBackMode/WS method and hope their heuristic matches something that makes sense in the portal. Basically, the example shows that if a consumer/portal doesn't have the means to express this information directly and it wants to ensure the highest possible degree of consistency it is forced to manipulate the validModes/WindowStates to get its desired result. For example in the situation that a consumer takes a portlet from VIEW->EDIT->HELP and wants to make sure the portlet unwinds through the entire stack it would set the validModes to VIEW, EDIT, and HELP when in EDIT mode but only EDIT and HELP when in HELP mode, thereby indicating its intent to prevent the hardcoded transition back to VIEW from HELP. Because validModes are provisional in WSRP, the portal/consumer will be forced to detect the inappropriate mode transition on request [from the portlet] and write code that interpretes the portlets intent. I.e. if the portlet is in Help mode as above and asks to return to View mode then I will interprete this as a request to go to the previous mode, hence put/render them in Edit mode. Some guess work is going on here but if the portal carefully controls its stack/validModes it can do the "right thing" most of the time. Now in the code example, shown in the forwarded message, you will see that the portlet/producer is forced to do the guessing. This is because though validModes/WS are provisional in WSRP they are not in JSR 168. A JSR 168 portlet can't set/request a mode that the portal indicates is invalid. [If you think about this, this is very reasonable behavior for a container built on top of WSRP trying to facilitate portlet development]. In the JSR 168 environment, the portlet tries a preferred 'Back' mode -- generally VIEW. But in the cases this fails it writes a heuristic to guess what it should really go back to. All in all, I suggest we would be much better off if neither the portlet/producer or portal/consumer had to do any guessing, hence the change request. One aside to remember in all this, is that for most portlets the only Mode transitions they will code will be 'Back' semantics to return from being in Edit mode or Help mode which the portal placed them into in the first place. I.e. most portlets rely on the portal to render links [in the portlet decoration] to move them into new modes. [And thereby getting a consistent UI]. Portlets however are forced to implement the buttons that control terminating these modes. -Mike- -------- Original Message -------- Return-Path: <jsr-168-redistribution-request@sun.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 h2JNUjB05190 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 16:30:45 -0700 (MST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNUio05016 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 16:30:44 -0700 (MST) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUhh11416 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 15:30:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUgW11406 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 15:30:42 -0800 (PST) Received: from sunmail3.sfbay.sun.com ([129.149.247.180]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02266; Wed, 19 Mar 2003 16:30:38 -0700 (MST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by sunmail3.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2JNUQk15440; Wed, 19 Mar 2003 15:30:26 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07535; Wed, 19 Mar 2003 15:30:25 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP; Wed, 19 Mar 2003 23:30:11 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Wed, 19 Mar 2003 23:26:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z Received: from swjscmail2.java.sun.com (swjscmail2.java.sun.com [192.18.99.108]) by relay11.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id 632C9213C0; Wed, 19 Mar 2003 16:26:01 -0700 (MST) Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6140685 for JSR-168-EG@JAVA.SUN.COM; Wed, 19 Mar 2003 16:23:23 -0700 Delivered-To: jsr-168-eg@jcp.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by swjscmail1.java.sun.com (Postfix) with ESMTP id 212FE484C for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 16:23:23 -0700 (MST) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2JNTUL25408 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 15:29:30 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNTTe25391 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 15:29:29 -0800 (PST) Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTTm09725 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 16:29:29 -0700 (MST) Received: from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTSt09709; Wed, 19 Mar 2003 16:29:28 -0700 (MST) 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <3E78FC82.4070005@oracle.com> Date: Wed, 19 Mar 2003 15:25:54 -0800 Reply-To: Java Community Process JSR #168 Expert List <JSR-168-EG@JCP.ORG> Sender: Java Community Process JSR #168 Expert List <JSR-168-EG@JCP.ORG> From: Michael Freedman <Michael.Freedman@oracle.com> Organization: Oracle Corporation Subject: Supporting 'Back' semantics Comments: To: jsr168 <JSR-168-EG@JCP.ORG> To: JSR-168-EG@JCP.ORG Just to make this issue real here is some sample code JSR 168 developers will have to write to deal with Edit/Help modes. Shouldn't we find an easier way for them to write this? And at the same time give the portal a little more influence over the result vs. merely manipulating the valid modes and window states. I.e. what is the value of forcing every developer to discover that in the end they need to write the equivalent of a getBackMode and getBackWindowState? I think the developer would prefer our API provide these methods. If/when we decide to do so, we should do so in a manner that gives the portal/container to represent the actual intent of the portal vs. relying on some generic heuristics related to what modes/states are valid. Note: all portlets will have to write something like this even if they are maintaining navigational state themselves as a Portal is allowed to manage navigation by manipulating the valid WS/Modes. However, if I were a portlet that maintained such state [can only be done if I have a session] then I might use this additional information to affect the order of my search. public void processEdit(ActionRequest request, ActionResponse response) throws PortletException { /* Detect which button was pushed [apply, cancel, ok] */ if (request.getParameter("apply") != null) { doApply(request, response); return; } else if (request.getParameter("ok") != null) { doApply(request, response); } // On either 'OK' ot 'Cancel' return to previous mode ..... try { /* see method below for how getBackMode is implemented */ response.setPortletMode(getBackMode(request)); } catch (PortletModeException pme) { /* Oops something went wrong with my hueristic to get a back mode */ throw new PortletException(...); } /* now do the exact same thing for setting the Back window state */ /* see method below for how getBackMode is implemented */ try { response.setWindowState(getBackWS(request)); } catch (WindowStateException wse) { /* Oops something went wrong with my hueristic to get a back mode */ throw new PortletException(...); } // ..... } public PortletMode getBackMode(PortletRequest request) { // always try and go back to VIEW mode -- if // this doesn't work then pick one that isn't the // current one. if (request.isValidPortletMode(PortletMode.VIEW)) return PortletMode.VIEW; else if (request.isValidPortletMode(PortletMode.EDIT) && !request.getMode().equals(PortletMode.EDIT)) return PortletMode.EDIT; else if (request.isValidPortletMode(PortletMode.HELP) && !request.getMode().equals(PortletMode.HELP)) return PortletMode.HELP; .... // have an additional else if clause for each custom // mode I recognize. // Oops -- fell out so merely use the current mode return request.getMode(); } public WindowState getBackWindowState(PortletRequest request) { // always try and go back to NORMAL mode -- if // this doesn't work then pick one that isn't the // current one. if (request.isValidWindowState(WindowState.NORMAL)) return WindowState.NORMAL; else if (request.isValidWindowState(WindowState.MAXIMIZED)) return WindowState.MAXIMIZED; else if (request.isValidWindowState(WindowState.MINIMIZED)) return WindowState.MINIMIZED; .... // have an additional else if clause for each custom // window state I recognize. // Oops -- fell out so merely use the current mode return request.getWindowState(); } -Mike- --------------040707060102080008080108 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> To further motivate why we should allow 'Back' semantics to be passed by the consumer in our protocol I have forwarded an e-mail I sent to the JSR 168 EG providing example code that shows that without such support the portlet developer is forced to invent/write their own getBackMode/WS method and hope their heuristic matches something that makes sense in the portal.<br> <br> Basically, the example shows that if a consumer/portal doesn't have the means to express this information directly and it wants to ensure the highest possible degree of consistency it is forced to manipulate the validModes/WindowStates to get its desired result. For example in the situation that a consumer takes a portlet from VIEW->EDIT->HELP and wants to make sure the portlet unwinds through the entire stack it would set the validModes to VIEW, EDIT, and HELP when in EDIT mode but only EDIT and HELP when in HELP mode, thereby indicating its intent to prevent the hardcoded transition back to VIEW from HELP. Because validModes are provisional in WSRP, the portal/consumer will be forced to detect the inappropriate mode transition on request [from the portlet] and write code that interpretes the portlets intent. I.e. if the portlet is in Help mode as above and asks to return to View mode then I will interprete this as a request to go to the previous mode, hence put/render them in Edit mode. Some guess work is going on here but if the portal carefully controls its stack/validModes it can do the "right thing" most of the time. <br> <br> Now in the code example, shown in the forwarded message, you will see that the portlet/producer is forced to do the guessing. This is because though validModes/WS are provisional in WSRP they are not in JSR 168. A JSR 168 portlet can't set/request a mode that the portal indicates is invalid. [If you think about this, this is very reasonable behavior for a container built on top of WSRP trying to facilitate portlet development]. In the JSR 168 environment, the portlet tries a preferred 'Back' mode -- generally VIEW. But in the cases this fails it writes a heuristic to guess what it should really go back to.<br> <br> All in all, I suggest we would be much better off if neither the portlet/producer or portal/consumer had to do any guessing, hence the change request. <br> <br> One aside to remember in all this, is that for most portlets the only Mode transitions they will code will be 'Back' semantics to return from being in Edit mode or Help mode which the portal placed them into in the first place. I.e. most portlets rely on the portal to render links [in the portlet decoration] to move them into new modes. [And thereby getting a consistent UI]. Portlets however are forced to implement the buttons that control terminating these modes.<br> <br> -Mike-<br> <br> -------- Original Message -------- <table cellpadding="0" cellspacing="0" border="0"> <tbody> <tr> <th valign="baseline" align="right" nowrap="nowrap">Return-Path: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:jsr-168-redistribution-request@sun.com"><jsr-168-redistribution-request@sun.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>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 h2JNUjB05190 for <a class="moz-txt-link-rfc2396E" href="mailto:jsr_168_us@oracle.com"><jsr_168_us@oracle.com></a>; Wed, 19 Mar 2003 16:30:45 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNUio05016 for <a class="moz-txt-link-rfc2396E" href="mailto:jsr_168_us@oracle.com"><jsr_168_us@oracle.com></a>; Wed, 19 Mar 2003 16:30:44 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUhh11416 for <a class="moz-txt-link-rfc2396E" href="mailto:jsr_168_us@oracle.com"><jsr_168_us@oracle.com></a>; Wed, 19 Mar 2003 15:30:43 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUgW11406 for <a class="moz-txt-link-rfc2396E" href="mailto:jsr_168_us@oracle.com"><jsr_168_us@oracle.com></a>; Wed, 19 Mar 2003 15:30:42 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from sunmail3.sfbay.sun.com ([129.149.247.180]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02266; Wed, 19 Mar 2003 16:30:38 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from nwkea-mail-1.sun.com ([192.18.42.13]) by sunmail3.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2JNUQk15440; Wed, 19 Mar 2003 15:30:26 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07535; Wed, 19 Mar 2003 15:30:25 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP; Wed, 19 Mar 2003 23:30:11 Z</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Wed, 19 Mar 2003 23:26:57 Z</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from swjscmail2.java.sun.com (swjscmail2.java.sun.com [192.18.99.108]) by relay11.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id 632C9213C0; Wed, 19 Mar 2003 16:26:01 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6140685 for <a class="moz-txt-link-abbreviated" href="mailto:JSR-168-EG@JAVA.SUN.COM">JSR-168-EG@JAVA.SUN.COM</a>; Wed, 19 Mar 2003 16:23:23 -0700</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Delivered-To: </th> <td><a class="moz-txt-link-abbreviated" href="mailto:jsr-168-eg@jcp.org">jsr-168-eg@jcp.org</a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by swjscmail1.java.sun.com (Postfix) with ESMTP id 212FE484C for <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a>; Wed, 19 Mar 2003 16:23:23 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2JNTUL25408 for <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a>; Wed, 19 Mar 2003 15:29:30 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNTTe25391 for <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a>; Wed, 19 Mar 2003 15:29:29 -0800 (PST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTTm09725 for <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a>; Wed, 19 Mar 2003 16:29:29 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Received: </th> <td>from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTSt09709; Wed, 19 Mar 2003 16:29:28 -0700 (MST)</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">User-Agent: </th> <td>Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">X-Accept-Language: </th> <td>en-us, en</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">MIME-Version: </th> <td>1.0</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Content-Type: </th> <td>text/plain; charset=us-ascii; format=flowed</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Content-Transfer-Encoding: </th> <td>7bit</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Message-Id: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:3E78FC82.4070005@oracle.com"><3E78FC82.4070005@oracle.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Date: </th> <td>Wed, 19 Mar 2003 15:25:54 -0800</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th> <td>Java Community Process JSR #168 Expert List <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Sender: </th> <td>Java Community Process JSR #168 Expert List <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">From: </th> <td>Michael Freedman <a class="moz-txt-link-rfc2396E" href="mailto:Michael.Freedman@oracle.com"><Michael.Freedman@oracle.com></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Organization: </th> <td>Oracle Corporation</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Subject: </th> <td>Supporting 'Back' semantics</td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">Comments: </th> <td>To: jsr168 <a class="moz-txt-link-rfc2396E" href="mailto:JSR-168-EG@JCP.ORG"><JSR-168-EG@JCP.ORG></a></td> </tr> <tr> <th valign="baseline" align="right" nowrap="nowrap">To: </th> <td><a class="moz-txt-link-abbreviated" href="mailto:JSR-168-EG@JCP.ORG">JSR-168-EG@JCP.ORG</a></td> </tr> </tbody> </table> <br> <br> <pre>Just to make this issue real here is some sample code JSR 168 developers will have to write to deal with Edit/Help modes. Shouldn't we find an easier way for them to write this? And at the same time give the portal a little more influence over the result vs. merely manipulating the valid modes and window states. I.e. what is the value of forcing every developer to discover that in the end they need to write the equivalent of a getBackMode and getBackWindowState? I think the developer would prefer our API provide these methods. If/when we decide to do so, we should do so in a manner that gives the portal/container to represent the actual intent of the portal vs. relying on some generic heuristics related to what modes/states are valid. Note: all portlets will have to write something like this even if they are maintaining navigational state themselves as a Portal is allowed to manage navigation by manipulating the valid WS/Modes. However, if I were a portlet that maintained such state [can only be done if I have a session] then I might use this additional information to affect the order of my search. public void processEdit(ActionRequest request, ActionResponse response) throws PortletException { /* Detect which button was pushed [apply, cancel, ok] */ if (request.getParameter("apply") != null) { doApply(request, response); return; } else if (request.getParameter("ok") != null) { doApply(request, response); } // On either 'OK' ot 'Cancel' return to previous mode ..... try { /* see method below for how getBackMode is implemented */ response.setPortletMode(getBackMode(request)); } catch (PortletModeException pme) { /* Oops something went wrong with my hueristic to get a back mode */ throw new PortletException(...); } /* now do the exact same thing for setting the Back window state */ /* see method below for how getBackMode is implemented */ try { response.setWindowState(getBackWS(request)); } catch (WindowStateException wse) { /* Oops something went wrong with my hueristic to get a back mode */ throw new PortletException(...); } // ..... } public PortletMode getBackMode(PortletRequest request) { // always try and go back to VIEW mode -- if // this doesn't work then pick one that isn't the // current one. if (request.isValidPortletMode(PortletMode.VIEW)) return PortletMode.VIEW; else if (request.isValidPortletMode(PortletMode.EDIT) && !request.getMode().equals(PortletMode.EDIT)) return PortletMode.EDIT; else if (request.isValidPortletMode(PortletMode.HELP) && !request.getMode().equals(PortletMode.HELP)) return PortletMode.HELP; .... // have an additional else if clause for each custom // mode I recognize. // Oops -- fell out so merely use the current mode return request.getMode(); } public WindowState getBackWindowState(PortletRequest request) { // always try and go back to NORMAL mode -- if // this doesn't work then pick one that isn't the // current one. if (request.isValidWindowState(WindowState.NORMAL)) return WindowState.NORMAL; else if (request.isValidWindowState(WindowState.MAXIMIZED)) return WindowState.MAXIMIZED; else if (request.isValidWindowState(WindowState.MINIMIZED)) return WindowState.MINIMIZED; .... // have an additional else if clause for each custom // window state I recognize. // Oops -- fell out so merely use the current mode return request.getWindowState(); } -Mike- </pre> </body> </html> --------------040707060102080008080108-- Received: (qmail 9436 invoked by uid 60881); 20 Mar 2003 02:33:00 -0000 Received: from subbu@bea.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-3.5/8.0):. Processed in 0.535707 secs); 20 Mar 2003 02:33:00 -0000 X-Spam-Status: No, hits=-3.5 required=8.0 Received: from unknown (HELO usmailrelay.bea.com) (63.96.163.10) by mail.oasis-open.org with SMTP; 20 Mar 2003 02:33:00 -0000 Received: from boulder.bea.com (boulder.bea.com [10.36.32.10]) by usmailrelay.bea.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h2K2emv02035 for <wsrp@lists.oasis-open.org>; Wed, 19 Mar 2003 18:40:48 -0800 (PST) Received: from bea.com ([10.61.4.125]) by boulder.bea.com (8.9.3+Sun/8.9.1) with ESMTP id TAA28566 for <wsrp@lists.oasis-open.org>; Wed, 19 Mar 2003 19:41:31 -0700 (MST) Message-ID: <3E792ABD.1080707@bea.com> Date: Wed, 19 Mar 2003 19:43:09 -0700 From: Subbu Allamaraju <subbu@bea.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WSRP <wsrp@lists.oasis-open.org> Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"] References: <3E78F310.9000807@oracle.com> In-Reply-To: <3E78F310.9000807@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Received: (qmail 26171 invoked by uid 60881); 20 Mar 2003 09:11:17 -0000 Received: from andre.kramer@eu.citrix.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(1.1/8.0):. Processed in 0.443884 secs); 20 Mar 2003 09:11:17 -0000 X-Spam-Status: No, hits=1.1 required=8.0 Received: from unknown (HELO gatekeeper.ctxuk.citrix.com) (195.153.38.114) by mail.oasis-open.org with SMTP; 20 Mar 2003 09:11:16 -0000 Received: from sh.ctxuk.citrix.com (sh.ctxuk.citrix.com [10.30.224.4]) by gatekeeper.ctxuk.citrix.com (8.8.7/BSCF-1.7) with ESMTP id JAA06455 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:19:06 GMT Received: from uk1mailscan01 (uk1mailscan01.ctxuk.citrix.com [10.30.224.37]) by sh.ctxuk.citrix.com (8.8.7/BSCF-1.7) with SMTP id JAA24457 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:19:05 GMT Received: from 10.30.224.101 by uk1mailscan01 (InterScan E-Mail VirusWall NT); Thu, 20 Mar 2003 09:19:05 -0000 Received: by hwexch01.ctxuk.citrix.com with Internet Mail Service (5.5.2653.19) id <DS6PTAGN>; Thu, 20 Mar 2003 09:19:05 -0000 Message-ID: <1ACB87DCF175EF4894C4DD2A48DD18723DF8CF@uk1exch01.ctxuk.citrix.com> From: Andre Kramer <andre.kramer@eu.citrix.com> To: wsrp@lists.oasis-open.org Subject: RE: [wsrp] [wsrp-wsia] [change request #239] Rewrite token Date: Thu, 20 Mar 2003 09:18:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-143ab8ce-8d30-4043-96fe-32bbe3cc4d47" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-143ab8ce-8d30-4043-96fe-32bbe3cc4d47 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EEC1.BC443280" ------_=_NextPart_001_01C2EEC1.BC443280 Content-Type: text/plain; charset="iso-8859-1" Good catch! How about renaming wsrp-rewriteResource to wsrp-requireRewrite instead? Much less impact (and wsrp-rewriteURL may not result in a URL but a namespaced token). regards, Andre -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 19 March 2003 20:43 To: wsrp@lists.oasis-open.org Subject: [wsrp] [wsrp-wsia] [change request #239] Rewrite token Document: Spec Section: 10.2.1 + Page/Line: 61/33 Requested by: Rich Thompson Old text: wsrp-rewrite New text: wsrp-rewriteURL Reasoning: I just noticed that we introduced a portlet URL parameter called wsrp-rewriteResource ... this conflicts with the desire to have the demarcating token be relatively unique. This proposal eliminates this conflict while increasing the uniqueness of the demarcations. ------_=_NextPart_001_01C2EEC1.BC443280 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=187091209-20032003><FONT face=Arial color=#0000ff size=2>Good catch! How about renaming wsrp-rewriteResource to wsrp-requireRewrite instead? Much less impact (and wsrp-rewriteURL may not result in a URL but a namespaced token).</FONT></SPAN></DIV> <DIV><SPAN class=187091209-20032003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=187091209-20032003><FONT face=Arial color=#0000ff size=2>regards,</FONT></SPAN></DIV> <DIV><SPAN class=187091209-20032003><FONT face=Arial color=#0000ff size=2>Andre</FONT></SPAN></DIV> <BLOCKQUOTE> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Rich Thompson [mailto:richt2@us.ibm.com]<BR><B>Sent:</B> 19 March 2003 20:43<BR><B>To:</B> wsrp@lists.oasis-open.org<BR><B>Subject:</B> [wsrp] [wsrp-wsia] [change request #239] Rewrite token<BR><BR></FONT></DIV><BR><FONT size=2><TT>Document: Spec<BR>Section: 10.2.1 +<BR>Page/Line: 61/33<BR>Requested by: Rich Thompson<BR>Old text: wsrp-rewrite<BR>New text: wsrp-rewriteURL<BR>Reasoning: I just noticed that we introduced a portlet URL parameter called wsrp-rewriteResource ... this conflicts with the desire to have the demarcating token be relatively unique. This proposal eliminates this conflict while increasing the uniqueness of the demarcations.</TT></FONT></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C2EEC1.BC443280-- ------=_NextPartTM-000-143ab8ce-8d30-4043-96fe-32bbe3cc4d47-- Received: (qmail 26755 invoked by uid 60881); 20 Mar 2003 09:26:18 -0000 Received: from andre.kramer@eu.citrix.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-1.0/8.0):. Processed in 1.257339 secs); 20 Mar 2003 09:26:18 -0000 X-Spam-Status: No, hits=-1.0 required=8.0 Received: from unknown (HELO gatekeeper.ctxuk.citrix.com) (195.153.38.114) by mail.oasis-open.org with SMTP; 20 Mar 2003 09:26:17 -0000 Received: from sh.ctxuk.citrix.com (sh.ctxuk.citrix.com [10.30.224.4]) by gatekeeper.ctxuk.citrix.com (8.8.7/BSCF-1.7) with ESMTP id JAA07033 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:34:06 GMT Received: from uk1mailscan01 (uk1mailscan01.ctxuk.citrix.com [10.30.224.37]) by sh.ctxuk.citrix.com (8.8.7/BSCF-1.7) with SMTP id JAA24735 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:34:05 GMT Received: from 10.30.224.101 by uk1mailscan01 (InterScan E-Mail VirusWall NT); Thu, 20 Mar 2003 09:34:05 -0000 Received: by hwexch01.ctxuk.citrix.com with Internet Mail Service (5.5.2653.19) id <DS6PTAK7>; Thu, 20 Mar 2003 09:34:05 -0000 Message-ID: <1ACB87DCF175EF4894C4DD2A48DD18723DF8D0@uk1exch01.ctxuk.citrix.com> From: Andre Kramer <andre.kramer@eu.citrix.com> To: WSRP <wsrp@lists.oasis-open.org> Subject: RE: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] Date: Thu, 20 Mar 2003 09:34:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Received: (qmail 19060 invoked by uid 60881); 20 Mar 2003 12:19:15 -0000 Received: from Eilon.Reshef@webcollage.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-1.0/8.0):. Processed in 0.855059 secs); 20 Mar 2003 12:19:15 -0000 X-Spam-Status: No, hits=-1.0 required=8.0 Received: from unknown (HELO webcollage.com) (199.203.179.226) by mail.oasis-open.org with SMTP; 20 Mar 2003 12:19:14 -0000 Received: from athena.elseweb.com (athena [192.168.1.30]) by webcollage.com (8.9.3+Sun/6.2.1) with ESMTP id OAA08885 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:27:04 +0200 (IST) Received: by mail.israel.elseweb.com with Internet Mail Service (5.5.2650.21) id <FYW7A55M>; Thu, 20 Mar 2003 14:27:03 +0200 Message-ID: <A1406401E3CCD31183B60004AC15C196FA32C3@mail.israel.elseweb.com> From: Eilon Reshef <Eilon.Reshef@webcollage.com> To: WSRP <wsrp@lists.oasis-open.org> Subject: RE: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] Date: Thu, 20 Mar 2003 14:27:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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. 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 Received: (qmail 20840 invoked by uid 60881); 20 Mar 2003 12:56:43 -0000 Received: from richt2@us.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(0.0/8.0):. Processed in 0.251735 secs); 20 Mar 2003 12:56:43 -0000 X-Spam-Status: No, hits=0.0 required=8.0 Received: from unknown (HELO e3.ny.us.ibm.com) (32.97.182.103) by mail.oasis-open.org with SMTP; 20 Mar 2003 12:56:42 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2KD4XkD174558 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 08:04:33 -0500 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KD4V8G114040 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 08:04:31 -0500 In-Reply-To: <3E791717.8000200@oracle.com> To: wsrp@lists.oasis-open.org MIME-Version: 1.0 Subject: [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Rich Thompson <richt2@us.ibm.com> Message-ID: <OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com> Date: Thu, 20 Mar 2003 08:04:30 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|March 14, 2003) at 03/20/2003 08:04:31, Serialize complete at 03/20/2003 08:04:31 Content-Type: multipart/alternative; boundary="=_alternative 0047D30F85256CEF_=" This is a multipart message in MIME format. --=_alternative 0047D30F85256CEF_= Content-Type: text/plain; charset="US-ASCII" Document: Spec Section: 6.2.1 + Page/Line: 43/21 Requested by: Michael Freedman Old text: Interface.UnsupportedLocale New text: remove this exception Reasoning: Do we really want the producer/portlet to throw this explicit exception if it can't match the requested locale? Wouldn't it be better if portlets thought of the consumers list as preferred locales and merely returned the markup with whatever locale it decided to use? The consumer could then decide what it wanted to do. This fits a little better in the world where the portlet is implemented in Java as parts/much of the content may come from resource bundles which always resolve to a default whether the requested locale exists or not. In the end, if a portlet wants to merely abort the render and return an exception it can always use Interface.OperationFailed. I.e. as the consumer has the portlet meta data that indicates what locales its supports it seems that those consumers that want to ban inappropriate locales can choose to do so be not calling the render method based on this information. Right now, a consumer that wants content no matter what is forced to explicitly pass * as the last entry in its list. --=_alternative 0047D30F85256CEF_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>Document: Spec<br> Section: 6.2.1 +<br> Page/Line: 43/21<br> Requested by: Michael Freedman<br> Old text: Interface.UnsupportedLocale<br> New text: remove this exception<br> Reasoning: Do we really want the producer/portlet to throw this explicit <br> exception if it can't match the requested locale? Wouldn't it be better <br> if portlets thought of the consumers list as preferred locales and <br> merely returned the markup with whatever locale it decided to use? The <br> consumer could then decide what it wanted to do. This fits a little <br> better in the world where the portlet is implemented in Java as <br> parts/much of the content may come from resource bundles which always <br> resolve to a default whether the requested locale exists or not. In the <br> end, if a portlet wants to merely abort the render and return an <br> exception it can always use Interface.OperationFailed. I.e. as the <br> consumer has the portlet meta data that indicates what locales its <br> supports it seems that those consumers that want to ban inappropriate <br> locales can choose to do so be not calling the render method based on <br> this information. Right now, a consumer that wants content no matter <br> what is forced to explicitly pass * as the last entry in its list.<br> </tt></font> --=_alternative 0047D30F85256CEF_=-- Received: (qmail 21173 invoked by uid 60881); 20 Mar 2003 13:01:17 -0000 Received: from richt2@us.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-0.3/8.0):. Processed in 0.197091 secs); 20 Mar 2003 13:01:17 -0000 X-Spam-Status: No, hits=-0.3 required=8.0 Received: from unknown (HELO e5.ny.us.ibm.com) (32.97.182.105) by mail.oasis-open.org with SMTP; 20 Mar 2003 13:01:17 -0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2KD97oe134600 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 08:09:07 -0500 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KD95u8145864 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 08:09:06 -0500 In-Reply-To: <OF2828D038.5E5A4499-ON85256CB4.004A9A9C-85256CB4.004AC05B@us.ibm.com> To: wsrp@lists.oasis-open.org MIME-Version: 1.0 Subject: [wsrp-wsia] [change request #241] Drop "user-facing" X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Rich Thompson <richt2@us.ibm.com> Message-ID: <OFD6C7F689.A48ABE0B-ON85256CEF.00480166-85256CEF.00483E6C@us.ibm.com> Date: Thu, 20 Mar 2003 08:09:04 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|March 14, 2003) at 03/20/2003 08:09:06, Serialize complete at 03/20/2003 08:09:06 Content-Type: multipart/alternative; boundary="=_alternative 00483E2985256CEF_=" This is a multipart message in MIME format. --=_alternative 00483E2985256CEF_= Content-Type: text/plain; charset="US-ASCII" Document: Spec Sections: 1 & 1.2 Requested by: Alejandro Abdelnur Old text: "user-facing web services" New text: "web services" Reasoning: There is not such a thing as "user-facing" web services. They produce information that will be presented to a user but that is the case for many web services. And the client (consumer) will have to do more or less transformations to display this information to the user. --=_alternative 00483E2985256CEF_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>Document: Spec</tt></font> <br><font size=2><tt>Sections: 1 & 1.2</tt></font> <br><font size=2><tt>Requested by: Alejandro Abdelnur<br> Old text: "user-facing web services"<br> New text: "web services"<br> Reasoning: There is not such a thing as "user-facing" web services. They produce information that will be presented to a user but that is the case for many web services. And the client (consumer) will have to do more or less transformations to display this information to the user.<br> <br> </tt></font> --=_alternative 00483E2985256CEF_=-- Received: (qmail 21495 invoked by uid 60881); 20 Mar 2003 13:08:07 -0000 Received: from SCHAECK@de.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(0.8/8.0):. Processed in 0.437532 secs); 20 Mar 2003 13:08:07 -0000 X-Spam-Status: No, hits=0.8 required=8.0 Received: from unknown (HELO d12lmsgate-5.de.ibm.com) (194.196.100.238) by mail.oasis-open.org with SMTP; 20 Mar 2003 13:08:06 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2KDFuOI040576 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:15:56 +0100 Received: from d12ml024.de.ibm.com (d12ml024_cs0 [9.165.223.22]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KDFpnc220642 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:15:51 +0100 Subject: Re: [wsrp] [wsrp-wsia] [change request #241] Drop "user-facing" To: Rich Thompson <richt2@us.ibm.com> Cc: wsrp@lists.oasis-open.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: <OFBBCE2FC2.9A6C6370-ONC1256CEF.0048609D-C1256CEF.0048F75B@de.ibm.com> From: "Thomas Schaeck" <SCHAECK@de.ibm.com> Date: Thu, 20 Mar 2003 14:15:50 +0100 X-MIMETrack: Serialize by Router on D12ML024/12/M/IBM(Release 5.0.9a |January 7, 2002) at 20/03/2003 14:15:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii The word "user-facing" is very important to catch the attention and to allow analysts, press and customers to put WSRP into the right drawer. WSRP services are indeed "user-facing", since they include presentation and generate markup fragments aggregatable in a generic fashion which is conceptually different from data-oriented web services which typically return data encoded in XML from which the presentation still has to be created in a service/data format specific way. Therefore, we should not drop the word "user facing". Best regards, Thomas |---------+----------------------------> | | Rich | | | Thompson/Watson/I| | | BM@IBMUS | | | | | | 03/20/2003 02:09 | | | PM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp@lists.oasis-open.org | | cc: | | Subject: [wsrp] [wsrp-wsia] [change request #241] Drop "user-facing" | | | >------------------------------------------------------------------------------------------------------------------------------| Document: Spec Sections: 1 & 1.2 Requested by: Alejandro Abdelnur Old text: "user-facing web services" New text: "web services" Reasoning: There is not such a thing as "user-facing" web services. They produce information that will be presented to a user but that is the case for many web services. And the client (consumer) will have to do more or less transformations to display this information to the user. Received: (qmail 26585 invoked by uid 60881); 20 Mar 2003 13:47:17 -0000 Received: from rexb@starbourne.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-2.2/8.0):. Processed in 0.567887 secs); 20 Mar 2003 13:47:17 -0000 X-Spam-Status: No, hits=-2.2 required=8.0 Received: from unknown (HELO smtp.covadmail.net) (63.65.120.63) by mail.oasis-open.org with SMTP; 20 Mar 2003 13:47:17 -0000 Received: (covad.net 17469 invoked from network); 20 Mar 2003 13:55:08 -0000 Received: from unknown (HELO ?66.167.78.187?) (66.167.78.187) by sun-qmail18 with SMTP; 20 Mar 2003 13:55:07 -0000 Mime-Version: 1.0 X-Sender: rexb@mail.starbourne.com Message-Id: <a05200f00ba9f76770db6@[69.3.93.74]> In-Reply-To: <A1406401E3CCD31183B60004AC15C196FA32C3@mail.israel.elseweb.com> References: <A1406401E3CCD31183B60004AC15C196FA32C3@mail.israel.elseweb.com> Date: Thu, 20 Mar 2003 05:55:05 -0800 To: Eilon Reshef <Eilon.Reshef@webcollage.com>, WSRP <wsrp@lists.oasis-open.org> From: Rex Brooks <rexb@starbourne.com> Subject: RE: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] Content-Type: text/plain; charset="us-ascii" ; format="flowed" I think we are buying unnecessary trouble if we defer this entire issue. I don't like drilling down into details on the particulars of buttons and naming conventions, but I don't see a way around it. This is another case of either inviting a myriad of hard-to-replace practices or setting the least number of options at the highest level possible. I think confining ourselves to current and previous user navigational states for window and mode, with OK, CANCEL AND APPLY seems like the least we need to do to prevent a quagmire of practices to sort out for v1.1-2. Ciao, Rex At 2:27 PM +0200 3/20/03, 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. > >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 -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com Received: (qmail 27317 invoked by uid 60881); 20 Mar 2003 13:53:58 -0000 Received: from subbu@bea.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-3.2/8.0):. Processed in 0.606295 secs); 20 Mar 2003 13:53:58 -0000 X-Spam-Status: No, hits=-3.2 required=8.0 Received: from unknown (HELO usmailrelay.bea.com) (63.96.163.10) by mail.oasis-open.org with SMTP; 20 Mar 2003 13:53:57 -0000 Received: from boulder.bea.com (boulder.bea.com [10.36.32.10]) by usmailrelay.bea.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h2KE1mv20879; Thu, 20 Mar 2003 06:01:48 -0800 (PST) Received: from bea.com (ada.bea.com [10.36.33.46]) by boulder.bea.com (8.9.3+Sun/8.9.1) with ESMTP id HAA15702; Thu, 20 Mar 2003 07:02:35 -0700 (MST) Message-ID: <3E79CA48.9030305@bea.com> Date: Thu, 20 Mar 2003 07:03:52 -0700 From: Subbu Allamaraju <subbu@bea.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eilon Reshef <Eilon.Reshef@webcollage.com> CC: WSRP <wsrp@lists.oasis-open.org> Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] References: <A1406401E3CCD31183B60004AC15C196FA32C3@mail.israel.elseweb.com> In-Reply-To: <A1406401E3CCD31183B60004AC15C196FA32C3@mail.israel.elseweb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Received: (qmail 27563 invoked by uid 60881); 20 Mar 2003 13:54:22 -0000 Received: from andre.kramer@eu.citrix.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(0.8/8.0):. Processed in 0.505146 secs); 20 Mar 2003 13:54:22 -0000 X-Spam-Status: No, hits=0.8 required=8.0 Received: from unknown (HELO gatekeeper.ctxuk.citrix.com) (195.153.38.114) by mail.oasis-open.org with SMTP; 20 Mar 2003 13:54:21 -0000 Received: from sh.ctxuk.citrix.com (sh.ctxuk.citrix.com [10.30.224.4]) by gatekeeper.ctxuk.citrix.com (8.8.7/BSCF-1.7) with ESMTP id OAA19360 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:02:12 GMT Received: from uk1mailscan01 (uk1mailscan01.ctxuk.citrix.com [10.30.224.37]) by sh.ctxuk.citrix.com (8.8.7/BSCF-1.7) with SMTP id OAA01291 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:02:11 GMT Received: from 10.30.224.101 by uk1mailscan01 (InterScan E-Mail VirusWall NT); Thu, 20 Mar 2003 14:02:11 -0000 Received: by hwexch01.ctxuk.citrix.com with Internet Mail Service (5.5.2653.19) id <DS6PTDT7>; Thu, 20 Mar 2003 14:02:11 -0000 Message-ID: <1ACB87DCF175EF4894C4DD2A48DD18723DF8D4@uk1exch01.ctxuk.citrix.com> From: Andre Kramer <andre.kramer@eu.citrix.com> To: wsrp@lists.oasis-open.org Subject: RE: [wsrp] [wsrp-wsia] [change request #240] Remove Interface.Uns upportedLocale fault Date: Thu, 20 Mar 2003 14:02:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0f8a0208-857e-4161-81c9-227d71fa5bd4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-0f8a0208-857e-4161-81c9-227d71fa5bd4 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EEE9.4B2323E0" ------_=_NextPart_001_01C2EEE9.4B2323E0 Content-Type: text/plain; charset="iso-8859-1" We don't require this fault to be thrown? All the fault says is that "the portlet does not support generating markup for the request locale". That could be taken to mean it is ok to generate markup (or a gif), even if the portlet can't localize to one of the requested locales, and not raise this fault. I would keep the fault but point out that it is optional (e.g. a contract would need to be in the right locale). regards, Andre -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 20 March 2003 13:05 To: wsrp@lists.oasis-open.org Subject: [wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault Document: Spec Section: 6.2.1 + Page/Line: 43/21 Requested by: Michael Freedman Old text: Interface.UnsupportedLocale New text: remove this exception Reasoning: Do we really want the producer/portlet to throw this explicit exception if it can't match the requested locale? Wouldn't it be better if portlets thought of the consumers list as preferred locales and merely returned the markup with whatever locale it decided to use? The consumer could then decide what it wanted to do. This fits a little better in the world where the portlet is implemented in Java as parts/much of the content may come from resource bundles which always resolve to a default whether the requested locale exists or not. In the end, if a portlet wants to merely abort the render and return an exception it can always use Interface.OperationFailed. I.e. as the consumer has the portlet meta data that indicates what locales its supports it seems that those consumers that want to ban inappropriate locales can choose to do so be not calling the render method based on this information. Right now, a consumer that wants content no matter what is forced to explicitly pass * as the last entry in its list. ------_=_NextPart_001_01C2EEE9.4B2323E0 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=878065613-20032003>We don't require this fault to be thrown? All the fault says is that "the portlet does not support generating markup for the request locale". That could be taken to mean it is ok to generate markup (or a gif), even if the portlet can't localize to one of the requested locales, and not raise this fault. I would keep the fault but point out that it is optional (e.g. a contract would need to be in the right locale).</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=878065613-20032003></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=878065613-20032003>regards,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=878065613-20032003>Andre</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=878065613-20032003></SPAN></FONT> </DIV> <BLOCKQUOTE> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Rich Thompson [mailto:richt2@us.ibm.com]<BR><B>Sent:</B> 20 March 2003 13:05<BR><B>To:</B> wsrp@lists.oasis-open.org<BR><B>Subject:</B> [wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault<BR><BR></FONT></DIV><BR><FONT size=2><TT>Document: Spec<BR>Section: 6.2.1 +<BR>Page/Line: 43/21<BR>Requested by: Michael Freedman<BR>Old text: Interface.UnsupportedLocale<BR>New text: remove this exception<BR>Reasoning: Do we really want the producer/portlet to throw this explicit <BR>exception if it can't match the requested locale? Wouldn't it be better <BR>if portlets thought of the consumers list as preferred locales and <BR>merely returned the markup with whatever locale it decided to use? The <BR>consumer could then decide what it wanted to do. This fits a little <BR>better in the world where the portlet is implemented in Java as <BR>parts/much of the content may come from resource bundles which always <BR>resolve to a default whether the requested locale exists or not. In the <BR>end, if a portlet wants to merely abort the render and return an <BR>exception it can always use Interface.OperationFailed. I.e. as the <BR>consumer has the portlet meta data that indicates what locales its <BR>supports it seems that those consumers that want to ban inappropriate <BR>locales can choose to do so be not calling the render method based on <BR>this information. Right now, a consumer that wants content no matter <BR>what is forced to explicitly pass * as the last entry in its list.<BR></BLOCKQUOTE></TT></FONT></BODY></HTML> ------_=_NextPart_001_01C2EEE9.4B2323E0-- ------=_NextPartTM-000-0f8a0208-857e-4161-81c9-227d71fa5bd4-- Received: (qmail 31267 invoked by uid 60881); 20 Mar 2003 14:39:58 -0000 Received: from richard.jacob@de.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-1.4/8.0):. Processed in 1.235035 secs); 20 Mar 2003 14:39:58 -0000 X-Spam-Status: No, hits=-1.4 required=8.0 Received: from unknown (HELO d12lmsgate-5.de.ibm.com) (194.196.100.238) by mail.oasis-open.org with SMTP; 20 Mar 2003 14:39:57 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2KEliOI099312 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 15:47:46 +0100 Received: from d12ml028.de.ibm.com (d12ml028_cs0 [9.165.223.24]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KElinc260150 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 15:47:44 +0100 In-Reply-To: <3E79CA48.9030305@bea.com> Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] To: wsrp@lists.oasis-open.org X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: <OF9EB78547.40C5B4AE-ONC1256CEF.0050537F-C1256CEF.005145D1@de.ibm.com> From: "Richard Jacob" <richard.jacob@de.ibm.com> Date: Thu, 20 Mar 2003 15:47:42 +0100 X-MIMETrack: Serialize by Router on D12ML028/12/M/IBM(Release 5.0.9a |January 7, 2002) at 20/03/2003 15:47:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I agree, I think we can't define *the* semantics for buttons. Again I'd like to repeat myself and state that this should only be done by the application, i.e. portlet. To give an example: we state below that APPLY naturally remaines in the same mode while OK leaves the mode (but to which mode? - here we go with the definition of back semantics). But portlets may explicitly want to stay in edit mode for example to display a success message and point out the changes made and so on. I think if we ask 10 developers about their semantics of OK, APPLY and whatever button we get 12 opinions. Therefor I would hesitate to try to push this into 1.0. I think we will also may have difficulties to define and agree which buttons make it into the CSS classes although I think this would be a reasonable thing to do. 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 |---------+----------------------------> | | Subbu Allamaraju | | | <subbu@bea.com> | | | | | | 03/20/2003 03:03 | | | PM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Eilon Reshef <Eilon.Reshef@webcollage.com> | | cc: WSRP <wsrp@lists.oasis-open.org> | | 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 Received: (qmail 31542 invoked by uid 60881); 20 Mar 2003 14:44:03 -0000 Received: from richt2@us.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-1.0/8.0):. Processed in 0.374026 secs); 20 Mar 2003 14:44:03 -0000 X-Spam-Status: No, hits=-1.0 required=8.0 Received: from unknown (HELO e5.ny.us.ibm.com) (32.97.182.105) by mail.oasis-open.org with SMTP; 20 Mar 2003 14:44:02 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2KEpsoe068484 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:51:54 -0500 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KEpq8G202562 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 09:51:52 -0500 In-Reply-To: <OF85CD3576.C11B82C9-ONC1256CED.002CD832-C1256CED.002D24EF@de.ibm.com> To: wsrp@lists.oasis-open.org MIME-Version: 1.0 Subject: Re: WSRP / WSIA TC Call Thursday, March 20th 8 am PST / 11 pm EST / 5 pm CET X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Rich Thompson <richt2@us.ibm.com> Message-ID: <OFDEEEEEF3.E990E400-ON85256CEF.004F6932-85256CEF.0051A70F@us.ibm.com> Date: Thu, 20 Mar 2003 09:51:49 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|March 14, 2003) at 03/20/2003 09:51:51, Serialize complete at 03/20/2003 09:51:51 Content-Type: multipart/alternative; boundary="=_alternative 0051A68685256CEF_=" This is a multipart message in MIME format. --=_alternative 0051A68685256CEF_= Content-Type: text/plain; charset="US-ASCII" The change requests (and current email discussion summaries) for today's call are: #138: How does info get to proxied resources => There is a proposal (worked on in the extended call last week) to define that any cookies the Producer sets on invocations for a portlet instance are also to be supplied to resources that portlet instance references subject to the standard cookie rules as per RFC 2109. #141: Add previous windowState and mode? => There has been little discussion about the actual focus of this CR. Is everyone agreed that the previousMode and previousWindowState fields need to be added back in? The semantics would be that the Consumer is supplying the values the Portlet should use for any URL seeking to return to the previous mode or window state. How the Consumer determines what those values are is implementation dependent. When and how the Portlet makes use of these values is also implementation dependent. #237: CSS Common Control classes () => There has been significant discussion about whether these are needed. Points I see being made are: Pro: These are required in order to achieve common look for standard controls. Con: The semantics of what applications choose to do varies so much that this would be in sufficient to address this area. (wrong level of abstraction). Suggestion: Place the concrete classes for common functionality into v1 as this addresses much of the functionality in a manner that current portlet developers understand and would likely adopt. Address how more abstract specification of controls can be done in v2. Current set of classes suggested and their semantics: wsrp-cancel: abort the current end-user activity. wsrp-apply: accept and apply the current end-user activity. Stay in current mode/windowState. wsrp-ok: accept and apply the current end-user activity. Exit current mode/windowState. wsrp-previous: navigate to previous page in the current end-user activity wsrp-next: navigate to the next page in the current end-user activity #238: No userAgent info => ?? => Proposal specifies a value of "" to be supplied whenever the Consumer does not have the data for this required field. #239: Rewrite token (wsrp-rewriteURL) => This notes that the wsrp-rewrite token is less unique due to the introduction of wsrp-rewriteResource portlet URL parameter. Suggestions include: 1. change token to wsrp-rewriteURL 2. change portlet URL parameter to wsrp-requiresRewrite #240: Remove Interface.UnsupportedLocale fault => This notes that this is not likely ever a desired fault. Do we want to define it or just use the OperationFailed fault for the few cases where it makes sense? #241: Drop "user-facing" => This notes that all web services needs some level of transformation before processing by a user agent. Why is WSRP specifically a user-facing web service definition? Thomas noted that this relates to generation of markup and processing user interaction with that markup. This is a summary phrase analysts, media, etc. pick up to understand that point. Rich Thompson Interaction Middleware and Standards for Portal Server IBM T.J. Watson Research Center Yorktown Heights, NY (914) 945-3225 richt2@us.ibm.com --=_alternative 0051A68685256CEF_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">The change requests (and current email discussion summaries) for today's call are:</font> <br> <br><font size=3 face="Times New Roman">#138: How does info get to proxied resources</font> <br><font size=3 face="Times New Roman"> => There is a proposal (worked on in the extended call last week) to define that any cookies the Producer sets on invocations for a portlet instance are also to be supplied to resources that portlet instance references subject to the standard cookie rules as per RFC 2109.</font> <br> <br><font size=3 face="Times New Roman">#141: Add previous windowState and mode?</font> <br><font size=3 face="Times New Roman"> => There has been little discussion about the actual focus of this CR. Is everyone agreed that the previousMode and previousWindowState fields need to be added back in? The semantics would be that the Consumer is supplying the values the Portlet should use for any URL seeking to return to the previous mode or window state. How the Consumer determines what those values are is implementation dependent. When and how the Portlet makes use of these values is also implementation dependent.</font> <br> <br><font size=3 face="Times New Roman">#237: CSS Common Control classes ()</font> <br><font size=3 face="Times New Roman"> => There has been significant discussion about whether these are needed. Points I see being made are:</font> <br><font size=3 face="Times New Roman"> Pro: These are required in order to achieve common look for standard controls.</font> <br><font size=3 face="Times New Roman"> Con: The semantics of what applications choose to do varies so much that this would be in sufficient to address this area. (wrong level of abstraction).</font> <br><font size=3 face="Times New Roman"> Suggestion: Place the concrete classes for common functionality into v1 as this addresses much of the functionality in a manner that current portlet developers understand and would likely adopt. Address how more abstract specification of controls can be done in v2.</font> <br><font size=3 face="Times New Roman"> Current set of classes suggested and their semantics:</font> <br><font size=3 face="Times New Roman"> </font><font size=2><tt> wsrp-cancel: abort the current end-user activity.<br> wsrp-apply: accept and apply the current end-user activity. Stay in current mode/windowState.<br> wsrp-ok: accept and apply the current end-user activity. Exit current mode/windowState.<br> wsrp-previous: navigate to previous page in the current end-user activity<br> wsrp-next: navigate to the next page in the current end-user activity</tt></font> <br> <br><font size=3 face="Times New Roman">#238: No userAgent info => ??</font> <br><font size=3 face="Times New Roman"> => Proposal specifies a value of "" to be supplied whenever the Consumer does not have the data for this required field.</font> <br> <br><font size=3 face="Times New Roman">#239: Rewrite token (wsrp-rewriteURL)</font> <br><font size=3 face="Times New Roman"> => This notes that the wsrp-rewrite token is less unique due to the introduction of wsrp-rewriteResource portlet URL parameter. Suggestions include:</font> <br><font size=3 face="Times New Roman"> 1. change token to wsrp-rewriteURL</font> <br><font size=3 face="Times New Roman"> 2. change portlet URL parameter to wsrp-requiresRewrite</font> <br> <br><font size=3 face="Times New Roman">#240: Remove Interface.UnsupportedLocale fault</font> <br><font size=3 face="Times New Roman"> => This notes that this is not likely ever a desired fault. Do we want to define it or just use the OperationFailed fault for the few cases where it makes sense?</font> <br> <br><font size=3 face="Times New Roman">#241: Drop "user-facing"</font> <br><font size=3 face="Times New Roman"> => This notes that all web services needs some level of transformation before processing by a user agent. Why is WSRP specifically a user-facing web service definition? Thomas noted that this relates to generation of markup and processing user interaction with that markup. This is a summary phrase analysts, media, etc. pick up to understand that point.</font> <br><font size=2 face="sans-serif"><br> Rich Thompson<br> Interaction Middleware and Standards for Portal Server<br> IBM T.J. Watson Research Center<br> Yorktown Heights, NY<br> (914) 945-3225<br> richt2@us.ibm.com</font> --=_alternative 0051A68685256CEF_=-- Received: (qmail 12107 invoked by uid 60881); 20 Mar 2003 18:17:08 -0000 Received: from SCHAECK@de.ibm.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(0.5/8.0):. Processed in 0.380249 secs); 20 Mar 2003 18:17:08 -0000 X-Spam-Status: No, hits=0.5 required=8.0 Received: from unknown (HELO d12lmsgate-4.de.ibm.com) (194.196.100.237) by mail.oasis-open.org with SMTP; 20 Mar 2003 18:17:07 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2KIOwdk093470; Thu, 20 Mar 2003 19:24:59 +0100 Received: from d12ml024.de.ibm.com (d12ml024_cs0 [9.165.223.22]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2KIOwnc256572; Thu, 20 Mar 2003 19:24:58 +0100 Subject: WebCollage IP Statement To: wsrp-wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: <OF4FC10246.A21A2040-ONC1256CEF.0064D51F-C1256CEF.00654425@de.ibm.com> From: "Thomas Schaeck" <SCHAECK@de.ibm.com> Date: Thu, 20 Mar 2003 19:24:57 +0100 X-MIMETrack: Serialize by Router on D12ML024/12/M/IBM(Release 5.0.9a |January 7, 2002) at 20/03/2003 19:24:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Here's the IP statement from Web Collage - it should appear on the OASIS WSRP TC Web Site within the next few days. This new one now has "royalty-free" in it - thanks Gil ! Best regards, Thomas Thomas Schaeck Chairman OASIS WSRP TC |---------+----------------------------> | | Gil Tayar | | | <Gil.Tayar@webcol| | | lage.com> | | | | | | 03/07/2003 01:26 | | | PM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Thomas Schaeck/Germany/IBM@IBMDE | | cc: Chai Natovich <Chai.Natovich@webcollage.com> | | Subject: WebCollage IP Statement | | | >------------------------------------------------------------------------------------------------------------------------------| Thomas, Following is the revised IP statement WebCollage is issuing to OASIS. It should replace the previous statement WebCollage has issued. Gil ------------------------------------------------------------------ March 7, 2003 To: OASIS Executive Director From: Mr. Chai Natovich, VP Finance and Operations, WebCollage Re: WebCollage Intellectual Property Rights WebCollage is a participant in the development of the OASIS WSRP Version 1.0 specification and the OASIS WSIA Version 1.0 specification. Consistent with the OASIS Policy on Intellectual Property Rights (http://www.oasis-open.org/who/intellectualproperty.shtml), WebCollage hereby notifies the OASIS Board of Directors that it believes it has at least one patent application with one or more pending claims related to compliant implementations of the OASIS WSRP Version 1.0 specification and the OASIS WSIA Version 1.0 specification. For example, WebCollage owns a published international patent application, DYNAMIC INTEGRATION OF WEB SITES, International Publication No. WO 01/77838, which claims priority to an unpublished U.S. patent application. WebCollage requests that the OASIS Board of Directors include in the specification documents a note indicating the existence of WebCollage's claimed intellectual property rights. To the extent WebCollage has or later obtains one or more patent claims necessary, in WebCollage's judgment, for implementation of the OASIS WSRP Version 1.0 specification and/or the OASIS WSIA Version 1.0 specification, WebCollage will, upon written request and if able, provide, to implementers of the OASIS WSRP Version 1.0 specification and/or the OASIS WSIA Version 1.0 specification, a nonexclusive and royalty-free patent license, with reasonable terms and conditions, for implementing the OASIS WSRP Version 1.0 specification and/or the OASIS WSIA Version 1.0 specification. The patent license shall be in writing and signed by WebCollage and the requesting entity, and it shall not include a license to any other intellectual property rights. If such entity has or later obtains rights related to one or both of these specifications, the requesting entity shall grant WebCollage a reciprocal license. All communications should be directed to: Mr. Chai Natovich VP Finance and Operations WebCollage Inc. 462 Seventh Avenue, 9th Floor New York, NY 10018 ------------------------------------------------------------------------ Received: (qmail 2245 invoked by uid 60881); 20 Mar 2003 21:06:37 -0000 Received: from alejandro.abdelnur@sun.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-3.2/8.0):. Processed in 0.18146 secs); 20 Mar 2003 21:06:37 -0000 X-Spam-Status: No, hits=-3.2 required=8.0 Received: from unknown (HELO nwkea-mail-2.sun.com) (192.18.42.14) by mail.oasis-open.org with SMTP; 20 Mar 2003 21:06:37 -0000 Received: from bighome.sfbay.sun.com ([129.145.155.115]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06202; Thu, 20 Mar 2003 13:14:29 -0800 (PST) Received: from sun.com (noidea.red.iplanet.com [192.18.146.11]) by bighome.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2KLET503581; Thu, 20 Mar 2003 13:14:29 -0800 (PST) Message-ID: <3E7A2F30.4010500@sun.com> Date: Thu, 20 Mar 2003 13:14:24 -0800 From: Alejandro Abdelnur <alejandro.abdelnur@sun.com> Organization: Sun Microsystems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rich Thompson <richt2@us.ibm.com> CC: wsrp@lists.oasis-open.org Subject: Re: [wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault References: <OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com> In-Reply-To: <OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> I agree with Mike's proposal of removing it from the spec and letting the producer/portlet to fallback to the most appropiate Locale available or throw an OperationFailed fault.<br> <br> Alejandro<br> <br> Rich Thompson wrote:<br> <blockquote type="cite" cite="midOFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com"> <br> <font size="2"><tt>Document: Spec<br> Section: 6.2.1 +<br> Page/Line: 43/21<br> Requested by: Michael Freedman<br> Old text: Interface.UnsupportedLocale<br> New text: remove this exception<br> Reasoning: Do we really want the producer/portlet to throw this explicit <br> exception if it can't match the requested locale? Wouldn't it be better <br> if portlets thought of the consumers list as preferred locales and <br> merely returned the markup with whatever locale it decided to use? The <br> consumer could then decide what it wanted to do. This fits a little <br> better in the world where the portlet is implemented in Java as <br> parts/much of the content may come from resource bundles which always <br> resolve to a default whether the requested locale exists or not. In the <br> end, if a portlet wants to merely abort the render and return an <br> exception it can always use Interface.OperationFailed. I.e. as the <br> consumer has the portlet meta data that indicates what locales its <br> supports it seems that those consumers that want to ban inappropriate <br> locales can choose to do so be not calling the render method based on <br> this information. Right now, a consumer that wants content no matter <br> what is forced to explicitly pass * as the last entry in its list.<br> </tt></font> </blockquote> </body> </html> Received: (qmail 7351 invoked by uid 60881); 20 Mar 2003 22:17:16 -0000 Received: from Michael.Freedman@oracle.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-1.0/8.0):. Processed in 0.303919 secs); 20 Mar 2003 22:17:16 -0000 X-Spam-Status: No, hits=-1.0 required=8.0 Received: from unknown (HELO inet-mail4.oracle.com) (148.87.2.204) by mail.oasis-open.org with SMTP; 20 Mar 2003 22:17:16 -0000 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2KMP7L15596 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:25:07 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KMP7e15589 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:25:07 -0800 (PST) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2KMP6c13860 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 15:25:06 -0700 (MST) Received: from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2KMP3O13776 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 15:25:04 -0700 (MST) Message-ID: <3E7A3EE8.9060704@oracle.com> Date: Thu, 20 Mar 2003 14:21:28 -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: WSRP <wsrp@lists.oasis-open.org> Subject: Alternative for supporting a control set style Content-Type: multipart/alternative; boundary="------------090301060805070306090403" --------------090301060805070306090403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As the conversation this morning was generally negative concerning adding additional CSS styles that could represent a set of mode controls I offer the following solution in lieu of working through a detailed design for something that will likely be rejected anyway. Basically, the solution focuses on communicating to the portlet "layout" information that a portlet could then use to make UI decisions. Passing such information is optional. Using the information is optional. However, portals that choose to pass such information can at least be ensured that the subset [hopefully large] that take it into consideration will yield a consistent UI within the portal. The argument for including this "special" layout information continue to be that our specification forces the portlet to render these controls however the consumer/portal has a vested interest in establishing a consistent L/F for these controls. Solution: Add the following optional field to MarkupParms: [O] ModeControlLayout modeControlLayout where ModeControlLayout is: ModeControlLayout [R] Controls controls[] [O] ControlOrientation controlOrientation [O] ControlAlignment controlAlignment Where Controls, ControlOrientation and ControlAlignment are restrictions on the string type that are contrained to specific values: Controls: "apply", "cancel", "ok", "reset", "previous", "next" ControlOrientation: "top", "bottom" ControlAlignment: "left", "center", "right" Members: * controls: This array defines the type and order of controls the portlet should use to be consistent with the Look/Feel for this consumers Mode controls. Portlets wishing to be consistent will render such controls, inconjunction with the other layout rules, preferrably by using WSRP predefined styles corresponding to these controls. * controlOrientation: The value of this field tells the portlet the consumers preferred orientation for the controls mentioned above. An orientation of "top" indicates a desire that the controls appear at the top [or first] of the modes rendition. An orientation of "bottom" indicates a desire that the controls appear at the bottom [or last] of the modes rendition. * controlAlignment: The value of this field tells the portlet how the consumer prefers the portlet align the controls mentioned above. A "left" alignment indicates a desire the controls be rendered flush left with respect to the overall content/form. A "center" alignment indicates a desire the controls be rendered centered with respect to the overall content/form. A "right" alignment indicates a desire the controls be rendered flush right with respect to the overall content/form. --------------090301060805070306090403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> As the conversation this morning was generally negative concerning adding additional CSS styles that could represent a set of mode controls I offer the following solution in lieu of working through a detailed design for something that will likely be rejected anyway. Basically, the solution focuses on communicating to the portlet "layout" information that a portlet could then use to make UI decisions. Passing such information is optional. Using the information is optional. However, portals that choose to pass such information can at least be ensured that the subset [hopefully large] that take it into consideration will yield a consistent UI within the portal. The argument for including this "special" layout information continue to be that our specification forces the portlet to render these controls however the consumer/portal has a vested interest in establishing a consistent L/F for these controls.<br> <br> Solution:<br> Add the following optional field to MarkupParms:<br> [O] ModeControlLayout modeControlLayout<br> <br> where ModeControlLayout is:<br> <br> ModeControlLayout<br> [R] Controls controls[]<br> [O] ControlOrientation controlOrientation<br> [O] ControlAlignment controlAlignment<br> <br> Where Controls, ControlOrientation and ControlAlignment are restrictions on the string type that are contrained to specific values:<br> Controls: "apply", "cancel", "ok", "reset", "previous", "next"<br> ControlOrientation: "top", "bottom"<br> ControlAlignment: "left", "center", "right"<br> <br> Members:<br> <ul> <li><i>controls: </i>This array defines the type and order of controls the portlet should use to be consistent with the Look/Feel for this consumers Mode controls. Portlets wishing to be consistent will render such controls, inconjunction with the other layout rules, preferrably by using WSRP predefined styles corresponding to these controls.</li> <li><i>controlOrientation</i>: The value of this field tells the portlet the consumers preferred orientation for the controls mentioned above. An orientation of "top" indicates a desire that the controls appear at the top [or first] of the modes rendition. An orientation of "bottom" indicates a desire that the controls appear at the bottom [or last] of the modes rendition.</li> <li><i>controlAlignment: </i>The value of this field tells the portlet how the consumer prefers the portlet align the controls mentioned above. A "left" alignment indicates a desire the controls be rendered flush left with respect to the overall content/form. A "center" alignment indicates a desire the controls be rendered centered with respect to the overall content/form. A "right" alignment indicates a desire the controls be rendered flush right with respect to the overall content/form.<br> </li> </ul> <br> <br> </body> </html> --------------090301060805070306090403-- Received: (qmail 8603 invoked by uid 60881); 20 Mar 2003 22:44:42 -0000 Received: from subbu@bea.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-2.9/8.0):. Processed in 0.222361 secs); 20 Mar 2003 22:44:42 -0000 X-Spam-Status: No, hits=-2.9 required=8.0 Received: from unknown (HELO usmailrelay.bea.com) (63.96.163.10) by mail.oasis-open.org with SMTP; 20 Mar 2003 22:44:41 -0000 Received: from boulder.bea.com (boulder.bea.com [10.36.32.10]) by usmailrelay.bea.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h2KMqXe15080 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 14:52:33 -0800 (PST) Received: from bea.com (ada.bea.com [10.36.33.46]) by boulder.bea.com (8.9.3+Sun/8.9.1) with ESMTP id PAA27879 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 15:53:21 -0700 (MST) Message-ID: <3E7A46B0.7050404@bea.com> Date: Thu, 20 Mar 2003 15:54:40 -0700 From: Subbu Allamaraju <subbu@bea.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WSRP <wsrp@lists.oasis-open.org> Subject: Re: [wsrp] Alternative for supporting a control set style References: <3E7A3EE8.9060704@oracle.com> In-Reply-To: <3E7A3EE8.9060704@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mike, Could you clarify what you mean by "the specification forces the portlet to render these controls"? Do you mean that WSRP forces portlets to always render these decorations? I can see that some portlets MAY want to render these (depends on the use case), but I don't see how the spec requires that portlets render these controls always? Subbu Michael Freedman wrote: > As the conversation this morning was generally negative concerning > adding additional CSS styles that could represent a set of mode > controls I offer the following solution in lieu of working through a > detailed design for something that will likely be rejected anyway. > Basically, the solution focuses on communicating to the portlet > "layout" information that a portlet could then use to make UI decisions. > Passing such information is optional. Using the information is > optional. However, portals that choose to pass such information can at > least be ensured that the subset [hopefully large] that take it into > consideration will yield a consistent UI within the portal. The > argument for including this "special" layout information continue to be > that our specification forces the portlet to render these controls > however the consumer/portal has a vested interest in establishing a > consistent L/F for these controls. > > Solution: > Add the following optional field to MarkupParms: > [O] ModeControlLayout modeControlLayout > > where ModeControlLayout is: > > ModeControlLayout > [R] Controls controls[] > [O] ControlOrientation controlOrientation > [O] ControlAlignment controlAlignment > > Where Controls, ControlOrientation and ControlAlignment are restrictions > on the string type that are contrained to specific values: > Controls: "apply", "cancel", "ok", "reset", "previous", "next" > ControlOrientation: "top", "bottom" > ControlAlignment: "left", "center", "right" > > Members: > > * /controls: /This array defines the type and order of controls the > portlet should use to be consistent with the Look/Feel for this > consumers Mode controls. Portlets wishing to be consistent will > render such controls, inconjunction with the other layout rules, > preferrably by using WSRP predefined styles corresponding to these > controls. > * /controlOrientation/: The value of this field tells the portlet > the consumers preferred orientation for the controls mentioned > above. An orientation of "top" indicates a desire that the > controls appear at the top [or first] of the modes rendition. An > orientation of "bottom" indicates a desire that the controls > appear at the bottom [or last] of the modes rendition. > * /controlAlignment: /The value of this field tells the portlet how > the consumer prefers the portlet align the controls mentioned > above. A "left" alignment indicates a desire the controls be > rendered flush left with respect to the overall content/form. A > "center" alignment indicates a desire the controls be rendered > centered with respect to the overall content/form. A "right" > alignment indicates a desire the controls be rendered flush right > with respect to the overall content/form. > > > Received: (qmail 11256 invoked by uid 60881); 20 Mar 2003 23:55:34 -0000 Received: from Michael.Freedman@oracle.com by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(-3.9/8.0):. Processed in 0.253992 secs); 20 Mar 2003 23:55:34 -0000 X-Spam-Status: No, hits=-3.9 required=8.0 Received: from unknown (HELO inet-mail2.oracle.com) (148.87.2.202) by mail.oasis-open.org with SMTP; 20 Mar 2003 23:55:33 -0000 Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2L03P720442 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 16:03:25 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail2.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2L03Oo20413 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 16:03:24 -0800 (PST) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2L03Nc01604 for <wsrp@lists.oasis-open.org>; Thu, 20 Mar 2003 17:03:23 -0700 (MST) Received: from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2L03NO01594; Thu, 20 Mar 2003 17:03:23 -0700 (MST) Message-ID: <3E7A55F4.7010409@oracle.com> Date: Thu, 20 Mar 2003 15:59:48 -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: WSRP <wsrp@lists.oasis-open.org> Subject: Re: [wsrp] Alternative for supporting a control set style References: <3E7A3EE8.9060704@oracle.com> <3E7A46B0.7050404@bea.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sure. Maybe a better way of saying this is the specification doesn't provide a way for consumers to render these controls: In particular one that processes the data and exits the mode. -Mike- Subbu Allamaraju wrote: > Mike, > > Could you clarify what you mean by "the specification forces the > portlet to render these controls"? Do you mean that WSRP forces > portlets to always render these decorations? I can see that some > portlets MAY want to render these (depends on the use case), but I > don't see how the spec requires that portlets render these controls > always? > > Subbu > > Michael Freedman wrote: > >> As the conversation this morning was generally negative concerning >> adding additional CSS styles that could represent a set of mode >> controls I offer the following solution in lieu of working through a >> detailed design for something that will likely be rejected anyway. >> Basically, the solution focuses on communicating to the portlet >> "layout" information that a portlet could then use to make UI >> decisions. Passing such information is optional. Using the >> information is optional. However, portals that choose to pass such >> information can at least be ensured that the subset [hopefully large] >> that take it into consideration will yield a consistent UI within the >> portal. The argument for including this "special" layout information >> continue to be that our specification forces the portlet to render >> these controls however the consumer/portal has a vested interest in >> establishing a consistent L/F for these controls. >> >> Solution: >> Add the following optional field to MarkupParms: >> [O] ModeControlLayout modeControlLayout >> >> where ModeControlLayout is: >> >> ModeControlLayout >> [R] Controls controls[] >> [O] ControlOrientation controlOrientation >> [O] ControlAlignment controlAlignment >> >> Where Controls, ControlOrientation and ControlAlignment are >> restrictions on the string type that are contrained to specific values: >> Controls: "apply", "cancel", "ok", "reset", "previous", "next" >> ControlOrientation: "top", "bottom" >> ControlAlignment: "left", "center", "right" >> >> Members: >> >> * /controls: /This array defines the type and order of controls the >> portlet should use to be consistent with the Look/Feel for this >> consumers Mode controls. Portlets wishing to be consistent will >> render such controls, inconjunction with the other layout rules, >> preferrably by using WSRP predefined styles corresponding to these >> controls. >> * /controlOrientation/: The value of this field tells the portlet >> the consumers preferred orientation for the controls mentioned >> above. An orientation of "top" indicates a desire that the >> controls appear at the top [or first] of the modes rendition. An >> orientation of "bottom" indicates a desire that the controls >> appear at the bottom [or last] of the modes rendition. >> * /controlAlignment: /The value of this field tells the portlet how >> the consumer prefers the portlet align the controls mentioned >> above. A "left" alignment indicates a desire the controls be >> rendered flush left with respect to the overall content/form. A >> "center" alignment indicates a desire the controls be rendered >> centered with respect to the overall content/form. A "right" >> alignment indicates a desire the controls be rendered flush right >> with respect to the overall content/form. >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]