Next in thread →
Next in month →
Re: [wsrp] Alternative for supporting a control set style
Title:
1. Does this provide enough guidance to
achieve the desired results?
I think its a good starting point that will work for most consumers. It
will not get one pixel perfect consistency, but by allowing the portlet to
display the proper set of buttons in the correct general location will feel
much more consistent then the current mechanism that ensures a random set
of button in random locations. Over time, more detailed guidance can be added
to reflect higher degrees of positioning/consistency.
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?
I really can't conceive of a replacement design that would require recoding
unless we completely reverse our decision that the portlet has total control
of what is rendered. Assuming we don't, the only reasonable alternative
I have been able to come up with is one that allows the consumer to pass
a Mode template to the producer into which it can write its [form] content.
The major troublesome element of this approach is limiting the amount of
parsing the producer has to do to insert its content -- this might be somewhat
hard as the producer not only has to locate where the bulk of the content
goes but also locate the buttons to write its action URLs. In any case,
like the solution above the portlet would be free to ignore this template
and write its own look/feel -- hence no rewriting of existing code would
be required.
-Mike-
Rich Thompson wrote:
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 <>
03/25/2003 01:43 PM
To:
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
<>
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.
>>
>>
>>
>
>
Next in thread →
Next in month →