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 <[EMAIL PROTECTED]> 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.
