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
