I created a Jira issue for this subject:
https://issues.apache.org/jira/browse/OFBIZ-3774
-Adrian
On 5/15/2010 4:11 AM, Marc Morin wrote:
Pure model objects with no behavior in them, and a visitor pattern to
externalize the behavior.... man, that's music to my ears!
We've added a visitor pattern to all the "model" objects, screens, forms,
menus, entity,....
It has proven invaluable to enable walking and manipulating the model, without
increasing the complexity of the underlying model objects.
Also, as your specific example indicates, the "renderers" are a perfect use
case for visitors, as the rendered is technically and interpreter of the model objects.
Marc
----- "Adrian Crum"<[email protected]> wrote:
--- On Fri, 5/14/10, Scott Gray<[email protected]> wrote:
On 15/05/2010, at 3:43 PM, Adrian
Crum wrote:
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.
That's crazy, I've been looking into this today. I
had figured on using an include-widget tag.
I was also thinking about the PITA way that we pass widget
renderers around and wondering if we couldn't just have a
render method on the model that takes a writer, the context
and a content type. The model then has an internal
factory that gets the configured renderer based on the
content type.
At least we're basically on the same page. My perspective all along is
that the screen widgets should be nothing more than data structures in
memory that support the visitor pattern. Renderers implement the
visitor interface. Implementations of the visitor interface could be
anything: HTML renderers, Swing renderers, artifact gatherers, layout
managers (an intermediate form of renderer), pretty printers, etc.
There is so much room for improvement, but experience has shown that
the screen widgets have become a sort of sacred cow, so changes like
that will be met with a lot of resistance.
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.
This sounds more like a custom renderer rather than
something that should go into the model.
It's not a custom renderer - the output is still the same as the
original view. It's just a different way of looking at screen
rendering. Instead of screen widgets calling scripts, a script calls
screen widgets. In other words, instead of XML-generated-widgets being
in charge of Groovy, Groovy is in charge of the XML-generated-widgets.
Think about it.
-Adrian
