[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"
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>
Received: (qmail 5928 invoked by uid 60881); 20 Mar 2003 15:32: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.8/8.0):.
Processed in 0.31433 secs); 20 Mar 2003 15:32:08 -0000
X-Spam-Status: No, hits=0.8 required=8.0
Received: from unknown (HELO d12lmsgate.de.ibm.com) (194.196.100.234)
by mail.oasis-open.org with SMTP; 20 Mar 2003 15:32:08 -0000
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2KFdwSo070048;
Thu, 20 Mar 2003 16:39:58 +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 h2KFdvnc243710;
Thu, 20 Mar 2003 16:39:57 +0100
Subject: Re: Can't make the teleconference today
To: "Danny Machak" <dmachak@tibco.com>,
"Richard Jacob" <richard.jacob@de.ibm.com>
Cc: Rich Thompson <richt2@us.ibm.com>, WSRP <wsrp-wsia@lists.oasis-open.org>
X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002
Message-ID: <OF8B317DE0.3C243416-ONC1256CEF.0055F400-C1256CEF.005628DB@de.ibm.com>
From: "Thomas Schaeck" <SCHAECK@de.ibm.com>
Date: Thu, 20 Mar 2003 16:39:56 +0100
X-MIMETrack: Serialize by Router on D12ML024/12/M/IBM(Release 5.0.9a |January 7, 2002) at
20/03/2003 16:39:57
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Danny,
hope your wife will be better soon ...
Richard,
could you please take minutes today ?
Best regards,
Thomas
Thomas Schaeck
Architect WebSphere Portal Server, STSM
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
schaeck@de.ibm.com Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
|---------+---------------------------->
| | "Danny Machak" |
| | <dmachak@tibco.co|
| | m> |
| | |
| | 03/20/2003 04:32 |
| | PM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Thomas Schaeck/Germany/IBM@IBMDE, Rich Thompson/Watson/IBM@IBMUS |
| cc: WSRP <wsrp-wsia@lists.oasis-open.org> |
| Subject: Can't make the teleconference today |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Hello Thomas and Rich,
Sorry for the late notice, but my wife came down with the
flu in the middle of the night, so I have to take care of
the kids this morning.
I hope you can find somebody to fill in as
secretary for this call.
Dan
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
------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]