wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org, wsrp-wsia@lists.oasis-open.org
- Date: Wed, 19 Mar 2003 13:44:38 -0500
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>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]