Revision 944898 contains an initial implementation of the screen widget factory. Right now it only works with screen sub-widgets. It could be extended to add a form field factory - so users could create custom field widgets.
It would be nice if we could take all of the sub-widget classes out of ModelScreenWidget.java and move them to a SubWidgets.java file. SubWidgets could implement WidgetLoader to register all of the contained classes with the factory. ModelScreenWidget.java would then be nothing more than an abstract class. Those changes would really help organize some of the widget code, but moving the classes around could be an issue for some users. -Adrian --- On Fri, 5/14/10, Adrian Crum <adrian.c...@yahoo.com> wrote: > From: Adrian Crum <adrian.c...@yahoo.com> > Subject: Screen Widget Ideas > To: dev@ofbiz.apache.org > Date: Friday, May 14, 2010, 8:43 PM > I've been thinking about some > improvements to the screen widgets, and I thought I would > offer some ideas and see if there is any interest. I'm kind > of thinking out loud here, so the ideas are not fully > developed. Please comment or add your suggestions. > > 1. Use the factory pattern to create model widgets. Right > now model widget construction is handled internally with a > pre-defined set of classes. The idea is to move the model > widget creation to a factory method that accepts a candidate > XML element. If a matching model widget is found, return it, > otherwise throw an exception. The factory supports > user-created model widgets, so the screen widgets are > extensible. In other words, you can create your own model > widgets, register them with the factory, and the screen > renderer will use them just like any other widget. You could > even create your own replacement implentations of existing > OFBiz screen widgets. User-created widgets can use > namespaces on the XML side to avoid XML parsing errors. > > 2. Add Groovy support to the <include-screen> widget. > If the location attribute ends with ".groovy" pass control > to the specified Groovy script. The script would behave like > a screen widget and it will have access to all model widgets > - so existing widget code can still be used. This could help > in certain cases where screen widgets can't fulfill a > particular need. It has been suggested that CDATA elements > be allowed in screen widgets so that free-form code can be > inserted in widget XML - this is an alternative solution to > that. The benefit is you can leverage the power of Groovy in > controlling screen output. The drawback is any such script > will break the structure of screen widgets and it will start > to look like JSP - where data preparation code is mixed with > presentation code. > > What do you think? Any other suggestions for improvements? > > -Adrian > > > > >
