Re: [wsrp] Alternative for supporting a control set style

[Michael Freedman <Michael.Freedman@oracle.com>]

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