Screen Widgets 3G

[Adrian Crum]

After working with the screen widgets for a while, and having modified
them too, I've come to the conclusion that the project could really
benefit from higher level screen widgets.

The first benefit I see is reduced XML code needed. I recently committed
a screenlet widget that significantly reduces the amount of XML needed
to create a screenlet.

There is a Jira issue open to discuss a standard Find screen layout
(https://issues.apache.org/jira/browse/OFBIZ-1635) and since nearly
every component has one or more Find screens, that could become a widget
too. An entire Find screen could be defined with 5 lines of XML.

The second benefit I see would be the reduction of screen widget
"hacks." Take for instance the following line

<container style="clear"/>

which is used to clear floats in a multicolumn page layout. The problem
with that line of widget code is that it is HTML specific. Other
rendering formats might not need to "clear floats."

A better solution would be to have an added attribute for the <section>
or <container> elements called "column-count" or something that
specifies the number of columns the section of screen contains. The
element would accept only <column> sub-elements. The HTML rendering
classes would be able to render the multi-column layout properly and
insert float clearing elements where necessary. Float clearing is no
longer the responsibility of the XML code.

I'm not suggesting that we go overboard and create widgets for every
collection of screen elements, but there are some screen element
collections that occur frequently enough that a widget for them would
reduce XML code and speed up the development process.

What do you think?

-Adrian

[Jacopo Cappellato]

Adrian,

this is a very interesting subject.
My first comment/question is: could we use the "decorator" pattern as a
simple way to define generic templates?
For example: we could have a decorator screen for the generic Find
screen (with placeholders for the parameters form and for the list
form); then the specific find screens will just use that decorator by
setting the form names to fill the placeholders.

Jacopo

Adrian Crum wrote:

> After working with the screen widgets for a while, and having modified
> them too, I've come to the conclusion that the project could really
> benefit from higher level screen widgets.
>
> The first benefit I see is reduced XML code needed. I recently committed
> a screenlet widget that significantly reduces the amount of XML needed
> to create a screenlet.
>
> There is a Jira issue open to discuss a standard Find screen layout
> (https://issues.apache.org/jira/browse/OFBIZ-1635) and since nearly
> every component has one or more Find screens, that could become a widget
> too. An entire Find screen could be defined with 5 lines of XML.
>
> The second benefit I see would be the reduction of screen widget
> "hacks." Take for instance the following line
>
> <container style="clear"/>
>
> which is used to clear floats in a multicolumn page layout. The problem
> with that line of widget code is that it is HTML specific. Other
> rendering formats might not need to "clear floats."
>
> A better solution would be to have an added attribute for the <section>
> or <container> elements called "column-count" or something that
> specifies the number of columns the section of screen contains. The
> element would accept only <column> sub-elements. The HTML rendering
> classes would be able to render the multi-column layout properly and
> insert float clearing elements where necessary. Float clearing is no
> longer the responsibility of the XML code.
>
> I'm not suggesting that we go overboard and create widgets for every
> collection of screen elements, but there are some screen element
> collections that occur frequently enough that a widget for them would
> reduce XML code and speed up the development process.
>
> What do you think?
>
> -Adrian

[Adrian Crum]

Jacopo,

That's a great suggestion. Let me try that out.

-Adrian

Jacopo Cappellato wrote:

> Adrian,
>
> this is a very interesting subject.
> My first comment/question is: could we use the "decorator" pattern as a
> simple way to define generic templates?
> For example: we could have a decorator screen for the generic Find
> screen (with placeholders for the parameters form and for the list
> form); then the specific find screens will just use that decorator by
> setting the form names to fill the placeholders.
>
> Jacopo
>
> Adrian Crum wrote:
>> After working with the screen widgets for a while, and having modified
>> them too, I've come to the conclusion that the project could really
>> benefit from higher level screen widgets.
>>
>> The first benefit I see is reduced XML code needed. I recently
>> committed a screenlet widget that significantly reduces the amount of
>> XML needed to create a screenlet.
>>
>> There is a Jira issue open to discuss a standard Find screen layout
>> (https://issues.apache.org/jira/browse/OFBIZ-1635) and since nearly
>> every component has one or more Find screens, that could become a
>> widget too. An entire Find screen could be defined with 5 lines of XML.
>>
>> The second benefit I see would be the reduction of screen widget
>> "hacks." Take for instance the following line
>>
>> <container style="clear"/>
>>
>> which is used to clear floats in a multicolumn page layout. The
>> problem with that line of widget code is that it is HTML specific.
>> Other rendering formats might not need to "clear floats."
>>
>> A better solution would be to have an added attribute for the
>> <section> or <container> elements called "column-count" or something
>> that specifies the number of columns the section of screen contains.
>> The element would accept only <column> sub-elements. The HTML
>> rendering classes would be able to render the multi-column layout
>> properly and insert float clearing elements where necessary. Float
>> clearing is no longer the responsibility of the XML code.
>>
>> I'm not suggesting that we go overboard and create widgets for every
>> collection of screen elements, but there are some screen element
>> collections that occur frequently enough that a widget for them would
>> reduce XML code and speed up the development process.
>>
>> What do you think?
>>
>> -Adrian
>
>

[Jacopo Cappellato]

A slightly different approach that I tried in the past, is implemented
in the "genericLink" common screen, that renders a link with page's
parameters appended to it (useful to implement an "Export" link to
export the result of a search, constrained by the page's parameters);
you should find some example of its usage in the facility application.

Jacopo


Adrian Crum wrote:

> Jacopo,
>
> That's a great suggestion. Let me try that out.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> Adrian,
>>
>> this is a very interesting subject.
>> My first comment/question is: could we use the "decorator" pattern as
>> a simple way to define generic templates?
>> For example: we could have a decorator screen for the generic Find
>> screen (with placeholders for the parameters form and for the list
>> form); then the specific find screens will just use that decorator by
>> setting the form names to fill the placeholders.
>>
>> Jacopo
>>
>> Adrian Crum wrote:
>>> After working with the screen widgets for a while, and having
>>> modified them too, I've come to the conclusion that the project could
>>> really benefit from higher level screen widgets.
>>>
>>> The first benefit I see is reduced XML code needed. I recently
>>> committed a screenlet widget that significantly reduces the amount of
>>> XML needed to create a screenlet.
>>>
>>> There is a Jira issue open to discuss a standard Find screen layout
>>> (https://issues.apache.org/jira/browse/OFBIZ-1635) and since nearly
>>> every component has one or more Find screens, that could become a
>>> widget too. An entire Find screen could be defined with 5 lines of XML.
>>>
>>> The second benefit I see would be the reduction of screen widget
>>> "hacks." Take for instance the following line
>>>
>>> <container style="clear"/>
>>>
>>> which is used to clear floats in a multicolumn page layout. The
>>> problem with that line of widget code is that it is HTML specific.
>>> Other rendering formats might not need to "clear floats."
>>>
>>> A better solution would be to have an added attribute for the
>>> <section> or <container> elements called "column-count" or something
>>> that specifies the number of columns the section of screen contains.
>>> The element would accept only <column> sub-elements. The HTML
>>> rendering classes would be able to render the multi-column layout
>>> properly and insert float clearing elements where necessary. Float
>>> clearing is no longer the responsibility of the XML code.
>>>
>>> I'm not suggesting that we go overboard and create widgets for every
>>> collection of screen elements, but there are some screen element
>>> collections that occur frequently enough that a widget for them would
>>> reduce XML code and speed up the development process.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>
>>

[David E Jones]

I agree with Jacopo. Using a decorator for this sort of thing instead  
of higher level elements reduces complexity for the higher volume  
cases, but retains flexibility.

In general with higher level screen widget elements, or even stuff  
that is totally independent of the screen widget, there is a danger in  
making things so high level and generic that flexibility is lost.

This has been discussed various times for different parts of OFBiz.  
For example in the simple-methods the decision was made to have  
separate elements for different parts of common processes rather than  
a single element for each variation on those steps. For example we have:

         <make-value entity-name="Example" value-name="newEntity"/>
         <sequenced-id-to-env sequence-name="Example" env-
name="newEntity.exampleId"/> <!-- get the next sequenced ID -->
         <field-to-result field-name="newEntity.exampleId" result-
name="exampleId"/>
         <set-nonpk-fields map-name="parameters" value-
name="newEntity"/>
         <create-value value-name="newEntity"/>

and

         <make-value entity-name="ExampleItem" value-name="newEntity"/>
         <set-pk-fields map-name="parameters" value-name="newEntity"/>
         <make-next-seq-id value-name="newEntity" seq-field-
name="exampleItemSeqId"/> <!-- this finds the next sub-sequence ID -->
         <field-to-result field-name="newEntity.exampleItemSeqId"  
result-name="exampleItemSeqId"/>
         <set-nonpk-fields map-name="parameters" value-
name="newEntity"/>
         <create-value value-name="newEntity"/>

and (hypothetically)

         <make-value entity-name="ExampleItem" value-name="newEntity"/>
         <set-pk-fields map-name="parameters" value-name="newEntity"/>
         <set-nonpk-fields map-name="parameters" value-
name="newEntity"/>
         <create-value value-name="newEntity"/>

instead of little one liners for each one. Each one of these could be  
effectively modeled as a single element and boom, less code. On a side  
note: admittedly the "sequenced-id-to-env" and "make-next-seq-id"  
elements are poorly named and could have been better named as  
"sequence-primary-key" and "sequence-secondary-key" or something (we  
might want to add/alias those at some point).

Anyway, the reason for doing that is flexibility. This is a pretty  
small set of operations, and could be smaller, but the problem with  
that is that if any flexibility was need it wouldn't be a simple  
change or a small variation, it would be a "rewrite".

-David


On Feb 13, 2008, at 11:31 AM, Adrian Crum wrote:

> Jacopo,
>
> That's a great suggestion. Let me try that out.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> Adrian,
>> this is a very interesting subject.
>> My first comment/question is: could we use the "decorator" pattern  
>> as a simple way to define generic templates?
>> For example: we could have a decorator screen for the generic Find  
>> screen (with placeholders for the parameters form and for the list  
>> form); then the specific find screens will just use that decorator  
>> by setting the form names to fill the placeholders.
>> Jacopo
>> Adrian Crum wrote:
>>> After working with the screen widgets for a while, and having  
>>> modified them too, I've come to the conclusion that the project  
>>> could really benefit from higher level screen widgets.
>>>
>>> The first benefit I see is reduced XML code needed. I recently  
>>> committed a screenlet widget that significantly reduces the amount  
>>> of XML needed to create a screenlet.
>>>
>>> There is a Jira issue open to discuss a standard Find screen  
>>> layout (https://issues.apache.org/jira/browse/OFBIZ-1635) and  
>>> since nearly every component has one or more Find screens, that  
>>> could become a widget too. An entire Find screen could be defined  
>>> with 5 lines of XML.
>>>
>>> The second benefit I see would be the reduction of screen widget  
>>> "hacks." Take for instance the following line
>>>
>>> <container style="clear"/>
>>>
>>> which is used to clear floats in a multicolumn page layout. The  
>>> problem with that line of widget code is that it is HTML specific.  
>>> Other rendering formats might not need to "clear floats."
>>>
>>> A better solution would be to have an added attribute for the  
>>> <section> or <container> elements called "column-count" or  
>>> something that specifies the number of columns the section of  
>>> screen contains. The element would accept only <column> sub-
>>> elements. The HTML rendering classes would be able to render the  
>>> multi-column layout properly and insert float clearing elements  
>>> where necessary. Float clearing is no longer the responsibility of  
>>> the XML code.
>>>
>>> I'm not suggesting that we go overboard and create widgets for  
>>> every collection of screen elements, but there are some screen  
>>> element collections that occur frequently enough that a widget for  
>>> them would reduce XML code and speed up the development process.
>>>
>>> What do you think?
>>>
>>> -Adrian

[Adrian Crum-2]

David,

Thank you for your comments!

I agree decorators can be used to reduce some widget code, but in several cases they result in the same amount of code or more.

Having higher level widgets doesn't make things any less flexible. Take the new screenlet widget for example. You can create a screenlet with 3 lines of code now. Is the screenlet widget too inflexible for your particular application? No problem - code it up using discreet widget elements.

One thing those discreet elements will never do that higher level widgets can do -change their behavior based upon their contents.  The screenlet's handling of a contained form's pagination menu is an example of that.

-Adrian

David E Jones <[hidden email]> wrote:
I agree with Jacopo. Using a decorator for this sort of thing instead  
of higher level elements reduces complexity for the higher volume  
cases, but retains flexibility.

In general with higher level screen widget elements, or even stuff  
that is totally independent of the screen widget, there is a danger in  
making things so high level and generic that flexibility is lost.

This has been discussed various times for different parts of OFBiz.  
For example in the simple-methods the decision was made to have  
separate elements for different parts of common processes rather than  
a single element for each variation on those steps. For example we have:

         
         
name="newEntity.exampleId"/>
         
name="exampleId"/>
         
name="newEntity"/>
         

and

         
         
         
name="exampleItemSeqId"/>
         
result-name="exampleItemSeqId"/>
         
name="newEntity"/>
         

and (hypothetically)

         
         
         
name="newEntity"/>
         

instead of little one liners for each one. Each one of these could be  
effectively modeled as a single element and boom, less code. On a side  
note: admittedly the "sequenced-id-to-env" and "make-next-seq-id"  
elements are poorly named and could have been better named as  
"sequence-primary-key" and "sequence-secondary-key" or something (we  
might want to add/alias those at some point).

Anyway, the reason for doing that is flexibility. This is a pretty  
small set of operations, and could be smaller, but the problem with  
that is that if any flexibility was need it wouldn't be a simple  
change or a small variation, it would be a "rewrite".

-David


On Feb 13, 2008, at 11:31 AM, Adrian Crum wrote:

> Jacopo,
>
> That's a great suggestion. Let me try that out.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> Adrian,
>> this is a very interesting subject.
>> My first comment/question is: could we use the "decorator" pattern  
>> as a simple way to define generic templates?
>> For example: we could have a decorator screen for the generic Find  
>> screen (with placeholders for the parameters form and for the list  
>> form); then the specific find screens will just use that decorator  
>> by setting the form names to fill the placeholders.
>> Jacopo
>> Adrian Crum wrote:
>>> After working with the screen widgets for a while, and having  
>>> modified them too, I've come to the conclusion that the project  
>>> could really benefit from higher level screen widgets.
>>>
>>> The first benefit I see is reduced XML code needed. I recently  
>>> committed a screenlet widget that significantly reduces the amount  
>>> of XML needed to create a screenlet.
>>>
>>> There is a Jira issue open to discuss a standard Find screen  
>>> layout (https://issues.apache.org/jira/browse/OFBIZ-1635) and  
>>> since nearly every component has one or more Find screens, that  
>>> could become a widget too. An entire Find screen could be defined  
>>> with 5 lines of XML.
>>>
>>> The second benefit I see would be the reduction of screen widget  
>>> "hacks." Take for instance the following line
>>>
>>>
>>>
>>> which is used to clear floats in a multicolumn page layout. The  
>>> problem with that line of widget code is that it is HTML specific.  
>>> Other rendering formats might not need to "clear floats."
>>>
>>> A better solution would be to have an added attribute for the  
>>>  or  elements called "column-count" or  
>>> something that specifies the number of columns the section of  
>>> screen contains. The element would accept only  sub-
>>> elements. The HTML rendering classes would be able to render the  
>>> multi-column layout properly and insert float clearing elements  
>>> where necessary. Float clearing is no longer the responsibility of  
>>> the XML code.
>>>
>>> I'm not suggesting that we go overboard and create widgets for  
>>> every collection of screen elements, but there are some screen  
>>> element collections that occur frequently enough that a widget for  
>>> them would reduce XML code and speed up the development process.
>>>
>>> What do you think?
>>>
>>> -Adrian

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

[Tim Ruppert]

Adrian, I'm sorry, but I've thought about this a lot and the  
decorators ARE useful all over the place.  Just my two cents, but I  
think the decorator has proven itself at designing reusable high level  
artifacts and I'd personally be reluctant to duplicate that logic in  
other places where it already exists.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Feb 17, 2008, at 10:33 AM, Adrian Crum wrote:

> David,
>
> Thank you for your comments!
>
> I agree decorators can be used to reduce some widget code, but in  
> several cases they result in the same amount of code or more.
>
> Having higher level widgets doesn't make things any less flexible.  
> Take the new screenlet widget for example. You can create a  
> screenlet with 3 lines of code now. Is the screenlet widget too  
> inflexible for your particular application? No problem - code it up  
> using discreet widget elements.
>
> One thing those discreet elements will never do that higher level  
> widgets can do -change their behavior based upon their contents.  
> The screenlet's handling of a contained form's pagination menu is an  
> example of that.
>
> -Adrian
>
> David E Jones <[hidden email]> wrote:
> I agree with Jacopo. Using a decorator for this sort of thing instead
> of higher level elements reduces complexity for the higher volume
> cases, but retains flexibility.
>
> In general with higher level screen widget elements, or even stuff
> that is totally independent of the screen widget, there is a danger in
> making things so high level and generic that flexibility is lost.
>
> This has been discussed various times for different parts of OFBiz.
> For example in the simple-methods the decision was made to have
> separate elements for different parts of common processes rather than
> a single element for each variation on those steps. For example we  
> have:
>
>
>
> name="newEntity.exampleId"/>
>
> name="exampleId"/>
>
> name="newEntity"/>
>
>
> and
>
>
>
>
> name="exampleItemSeqId"/>
>
> result-name="exampleItemSeqId"/>
>
> name="newEntity"/>
>
>
> and (hypothetically)
>
>
>
>
> name="newEntity"/>
>
>
> instead of little one liners for each one. Each one of these could be
> effectively modeled as a single element and boom, less code. On a side
> note: admittedly the "sequenced-id-to-env" and "make-next-seq-id"
> elements are poorly named and could have been better named as
> "sequence-primary-key" and "sequence-secondary-key" or something (we
> might want to add/alias those at some point).
>
> Anyway, the reason for doing that is flexibility. This is a pretty
> small set of operations, and could be smaller, but the problem with
> that is that if any flexibility was need it wouldn't be a simple
> change or a small variation, it would be a "rewrite".
>
> -David
>
>
> On Feb 13, 2008, at 11:31 AM, Adrian Crum wrote:
>
>> Jacopo,
>>
>> That's a great suggestion. Let me try that out.
>>
>> -Adrian
>>
>> Jacopo Cappellato wrote:
>>> Adrian,
>>> this is a very interesting subject.
>>> My first comment/question is: could we use the "decorator" pattern
>>> as a simple way to define generic templates?
>>> For example: we could have a decorator screen for the generic Find
>>> screen (with placeholders for the parameters form and for the list
>>> form); then the specific find screens will just use that decorator
>>> by setting the form names to fill the placeholders.
>>> Jacopo
>>> Adrian Crum wrote:
>>>> After working with the screen widgets for a while, and having
>>>> modified them too, I've come to the conclusion that the project
>>>> could really benefit from higher level screen widgets.
>>>>
>>>> The first benefit I see is reduced XML code needed. I recently
>>>> committed a screenlet widget that significantly reduces the amount
>>>> of XML needed to create a screenlet.
>>>>
>>>> There is a Jira issue open to discuss a standard Find screen
>>>> layout (https://issues.apache.org/jira/browse/OFBIZ-1635) and
>>>> since nearly every component has one or more Find screens, that
>>>> could become a widget too. An entire Find screen could be defined
>>>> with 5 lines of XML.
>>>>
>>>> The second benefit I see would be the reduction of screen widget
>>>> "hacks." Take for instance the following line
>>>>
>>>>
>>>>
>>>> which is used to clear floats in a multicolumn page layout. The
>>>> problem with that line of widget code is that it is HTML specific.
>>>> Other rendering formats might not need to "clear floats."
>>>>
>>>> A better solution would be to have an added attribute for the
>>>> or  elements called "column-count" or
>>>> something that specifies the number of columns the section of
>>>> screen contains. The element would accept only  sub-
>>>> elements. The HTML rendering classes would be able to render the
>>>> multi-column layout properly and insert float clearing elements
>>>> where necessary. Float clearing is no longer the responsibility of
>>>> the XML code.
>>>>
>>>> I'm not suggesting that we go overboard and create widgets for
>>>> every collection of screen elements, but there are some screen
>>>> element collections that occur frequently enough that a widget for
>>>> them would reduce XML code and speed up the development process.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>
>
>
>
> ---------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  
> Try it now.

[David E Jones]

On Feb 17, 2008, at 10:33 AM, Adrian Crum wrote:

> David,
>
> Thank you for your comments!
>
> I agree decorators can be used to reduce some widget code, but in  
> several cases they result in the same amount of code or more.

If you are looking at lines of code, then often yes. If you are  
looking at the complexity of the code, then generally no.

> Having higher level widgets doesn't make things any less flexible.  
> Take the new screenlet widget for example. You can create a  
> screenlet with 3 lines of code now. Is the screenlet widget too  
> inflexible for your particular application? No problem - code it up  
> using discreet widget elements.

That last sentence is exactly what is meant by limited flexibility. In  
other words, you either do exactly what it supports, or you don't use  
it at all.

> One thing those discreet elements will never do that higher level  
> widgets can do -change their behavior based upon their contents.  
> The screenlet's handling of a contained form's pagination menu is an  
> example of that.

A good example of balance between high/low level might be to have some  
more generic pagination widget instead of having to go through the  
screenlet widget.

-David

> David E Jones <[hidden email]> wrote:
> I agree with Jacopo. Using a decorator for this sort of thing instead
> of higher level elements reduces complexity for the higher volume
> cases, but retains flexibility.
>
> In general with higher level screen widget elements, or even stuff
> that is totally independent of the screen widget, there is a danger in
> making things so high level and generic that flexibility is lost.
>
> This has been discussed various times for different parts of OFBiz.
> For example in the simple-methods the decision was made to have
> separate elements for different parts of common processes rather than
> a single element for each variation on those steps. For example we  
> have:
>
>
>
> name="newEntity.exampleId"/>
>
> name="exampleId"/>
>
> name="newEntity"/>
>
>
> and
>
>
>
>
> name="exampleItemSeqId"/>
>
> result-name="exampleItemSeqId"/>
>
> name="newEntity"/>
>
>
> and (hypothetically)
>
>
>
>
> name="newEntity"/>
>
>
> instead of little one liners for each one. Each one of these could be
> effectively modeled as a single element and boom, less code. On a side
> note: admittedly the "sequenced-id-to-env" and "make-next-seq-id"
> elements are poorly named and could have been better named as
> "sequence-primary-key" and "sequence-secondary-key" or something (we
> might want to add/alias those at some point).
>
> Anyway, the reason for doing that is flexibility. This is a pretty
> small set of operations, and could be smaller, but the problem with
> that is that if any flexibility was need it wouldn't be a simple
> change or a small variation, it would be a "rewrite".
>
> -David
>
>
> On Feb 13, 2008, at 11:31 AM, Adrian Crum wrote:
>
>> Jacopo,
>>
>> That's a great suggestion. Let me try that out.
>>
>> -Adrian
>>
>> Jacopo Cappellato wrote:
>>> Adrian,
>>> this is a very interesting subject.
>>> My first comment/question is: could we use the "decorator" pattern
>>> as a simple way to define generic templates?
>>> For example: we could have a decorator screen for the generic Find
>>> screen (with placeholders for the parameters form and for the list
>>> form); then the specific find screens will just use that decorator
>>> by setting the form names to fill the placeholders.
>>> Jacopo
>>> Adrian Crum wrote:
>>>> After working with the screen widgets for a while, and having
>>>> modified them too, I've come to the conclusion that the project
>>>> could really benefit from higher level screen widgets.
>>>>
>>>> The first benefit I see is reduced XML code needed. I recently
>>>> committed a screenlet widget that significantly reduces the amount
>>>> of XML needed to create a screenlet.
>>>>
>>>> There is a Jira issue open to discuss a standard Find screen
>>>> layout (https://issues.apache.org/jira/browse/OFBIZ-1635) and
>>>> since nearly every component has one or more Find screens, that
>>>> could become a widget too. An entire Find screen could be defined
>>>> with 5 lines of XML.
>>>>
>>>> The second benefit I see would be the reduction of screen widget
>>>> "hacks." Take for instance the following line
>>>>
>>>>
>>>>
>>>> which is used to clear floats in a multicolumn page layout. The
>>>> problem with that line of widget code is that it is HTML specific.
>>>> Other rendering formats might not need to "clear floats."
>>>>
>>>> A better solution would be to have an added attribute for the
>>>> or  elements called "column-count" or
>>>> something that specifies the number of columns the section of
>>>> screen contains. The element would accept only  sub-
>>>> elements. The HTML rendering classes would be able to render the
>>>> multi-column layout properly and insert float clearing elements
>>>> where necessary. Float clearing is no longer the responsibility of
>>>> the XML code.
>>>>
>>>> I'm not suggesting that we go overboard and create widgets for
>>>> every collection of screen elements, but there are some screen
>>>> element collections that occur frequently enough that a widget for
>>>> them would reduce XML code and speed up the development process.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>
>
>
>
> ---------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  
> Try it now.

[Adrian Crum]

David E Jones wrote:
> On Feb 17, 2008, at 10:33 AM, Adrian Crum wrote:
>> One thing those discreet elements will never do that higher level
>> widgets can do -change their behavior based upon their contents.  The
>> screenlet's handling of a contained form's pagination menu is an
>> example of that.
>
> A good example of balance between high/low level might be to have some
> more generic pagination widget instead of having to go through the
> screenlet widget.

That's a great suggestion! I was thinking along the same lines while I
was working on the screenlet widget.

The problem with the form widget is that it has gotten very monolithic.
The pagination menu code is intertwined with the rest of the code, so
manipulating the pagination menu is impossible. I was thinking at the
time that I'd like to refactor that so that the form widget pagination
is contained in a Menu subwidget - which can be extracted and
manipulated, or replaced.

-Adrian

[David E Jones]

On Feb 18, 2008, at 8:26 AM, Adrian Crum wrote:

> David E Jones wrote:
>> On Feb 17, 2008, at 10:33 AM, Adrian Crum wrote:
>>> One thing those discreet elements will never do that higher level  
>>> widgets can do -change their behavior based upon their contents.  
>>> The screenlet's handling of a contained form's pagination menu is  
>>> an example of that.
>> A good example of balance between high/low level might be to have  
>> some more generic pagination widget instead of having to go through  
>> the screenlet widget.
>
> That's a great suggestion! I was thinking along the same lines while  
> I was working on the screenlet widget.
>
> The problem with the form widget is that it has gotten very  
> monolithic. The pagination menu code is intertwined with the rest of  
> the code, so manipulating the pagination menu is impossible. I was  
> thinking at the time that I'd like to refactor that so that the form  
> widget pagination is contained in a Menu subwidget - which can be  
> extracted and manipulated, or replaced.

You're absolutely right. It would be more flexible if there were  
external pagination options. Having pagination as part of the Form  
Widget is similar to having pagination as part of the screenlet.

Although... if the Form Widget does it's own query in an action that  
may not work so well (or it might work fine... hmmmm...). Anyway, it  
would be interesting to look into.

-David

[Adrian Crum]

David E Jones wrote:

>
> On Feb 18, 2008, at 8:26 AM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> On Feb 17, 2008, at 10:33 AM, Adrian Crum wrote:
>>>> One thing those discreet elements will never do that higher level
>>>> widgets can do -change their behavior based upon their contents.  
>>>> The screenlet's handling of a contained form's pagination menu is an
>>>> example of that.
>>> A good example of balance between high/low level might be to have
>>> some more generic pagination widget instead of having to go through
>>> the screenlet widget.
>>
>> That's a great suggestion! I was thinking along the same lines while I
>> was working on the screenlet widget.
>>
>> The problem with the form widget is that it has gotten very
>> monolithic. The pagination menu code is intertwined with the rest of
>> the code, so manipulating the pagination menu is impossible. I was
>> thinking at the time that I'd like to refactor that so that the form
>> widget pagination is contained in a Menu subwidget - which can be
>> extracted and manipulated, or replaced.
>
> You're absolutely right. It would be more flexible if there were
> external pagination options. Having pagination as part of the Form
> Widget is similar to having pagination as part of the screenlet.
>
> Although... if the Form Widget does it's own query in an action that may
> not work so well (or it might work fine... hmmmm...). Anyway, it would
> be interesting to look into.

The way the screenlet widget handles that now (and I plan on changing
that) is it runs the form widget's actions before displaying the
pagination menu. That results in running the form widget's actions twice
- so I'd like to work on that more and get a 'smarter' implementation done.


I'll make a note of what we've discussed so far and work on it after I
finish up some of the other things I have going on.

-Adrian