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:
There is an advantage to the portlet developer to having a single [standard] way to access this information vs. coding to N different cases.  There are many other places in the specification is which optional but useful information is passed where the same observation [that it could be an extension] applies.  I believe because of the way the protocol has been designed we have a responsibility in 1.0 to allow the consumer [to at a minimum] to communicate UI guidance to the the producer for controlling Edit and Help modes.  Turning your question around, why should we tell every portlet developer if they are interested in having their portlets provide a consistent L/F for mode controls they must consult each portal they may be registered with for details  and code accordingly?  This puts the developer in the unfortunate position of pre-guessing all the consumer types the customer/adminstrator may accept bindings/registrations from.  I.e. My philosophy is that extensions should be used by developers for "prefered" consumers for example an extended Mode.  But extensions shouldn't be used to manage function implied by the specification.
     -Mike-  

Eilon Reshef wrote:
Message
Is there any compelling reason not to treat this as a vendor extension for v1.0?
 
With what we have today, portlets can always determine based on the portal identity how to render the controls, if they wish to, so the preferred layout for portal vendors can be published as a vendor-specific set of guidelines.
 
Eilon
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, March 21, 2003 15:55
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] Alternative for supporting a control set style


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]