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
