Title: Message
Is there any compelling reason not to treat this as a vendor extension
for v1.0?
With what we have today, portlets can always determine based on the
portal identity how to render the controls, if they wish to, so the preferred
layout for portal vendors can be published as a vendor-specific set of
guidelines.
Eilon
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Friday, March 21, 2003
15:55
To:
Subject: Re: [wsrp]
Alternative for supporting a control set style
Not sure how I would evaluate this yet, but in the interest of
reducing the processing complexity for the portlet developer, I would suggest
the following tweaks on Mike's proposal:
Add the following optional field to MarkupParms:
[O]
ControlLayout controlLayout
Where ControlLayout
is:
ControlLayout
[O] string topControls[]
[O] string bottomControls[]
Where the values are
constrained to specific values:
"wsrp-apply",
"wsrp-cancel", "wsrp-ok", "wsrp-reset",
"wsrp-previous", and "wsrp-next"
and
the order within each of the two arrays is the flow order in the orientation
in use on the page (i.e. normally left to right).
Rich Thompson
Michael Freedman
<>
03/20/2003 06:59 PM
To:
WSRP <>
cc:
Subject: Re: [wsrp] Alternative
for supporting a control set
style
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.
>>
>>
>>
>
>
