[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]