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.
>>
>>
>>
>
>
