Title:
I am not/don't forsee the need for a consumer to have controls in both the
header and footer of the mode rendition. Because of this I don't see how
this reduces the processing complexity other then it eliminates the ability
for portlets to receive/utilize alignment information. In your proposal
the developer uses an "if (topControls != nil) check to determine whether
top or bottom is needed. In my case the code is "if (controlOrientation.equalsIgnoreCase("top"))".
In addition, I think my proposal gives the developer more flexibilty. I.e.
if all I care about is which buttons to display but want to ignore the layout
guidance I just use the information in the controls array. Likewise, I think
my proposal lends itself a little more naturally to extensions. For example
further information concerning L/F such as PreviousMode/WS. [In discussing
this I realize I neglected to include the requiste extension field in the
structure.
-Mike-
Rich Thompson wrote:
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.
>>
>>
>>
>
>
