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 <[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 thana 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.
smime.p7s
Description: S/MIME cryptographic signature
