OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]