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

[Rich Thompson <richt2@us.ibm.com>]

I had not understood from your original
proposal that the order in the control array would be the flow order of
the controls, though I now see this is stated. Also, the orientation and
alignment fields are informing the Portlet where the "normal"
placement of the control set is for this Consumer page in the specified
mode/window state. The intended result is that the Consumer has supplied
information to the Portlet which it may choose to use when placing controls
so that a base level of consistency is achieved. Portlets wishing to place
the controls in a manner more integrated with the rest of the content are
still free to do so.

I guess a couple of key questions for
me are:
  1. Does this provide enough guidance
to achieve the desired results?
  2. Are we likely to design a
more thorough means in v2 that effectively replaces this, but as a result
requires that Portlets be recoded to the new technique?

Rich Thompson

Michael Freedman <Michael.Freedman@oracle.com> 03/25/2003 01:43 PM

To:        wsrp@lists.oasis-open.org         cc:                 Subject:        Re: [wsrp] Alternative for supporting a control set style

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 <Michael.Freedman@oracle.com> 03/20/2003 06:59 PM

To:        WSRP <wsrp@lists.oasis-open.org>        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.
>>
>>
>>
>
>