Factory for creating model objects is a good idea. Allows opportunity to subclass them.
Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com ----- "Adrian Crum" <adrian.c...@yahoo.com> wrote: > Marc, > > Do you have any thoughts on the first two ideas I proposed? > > -Adrian > > --- On Sat, 5/15/10, Marc Morin <m...@emforium.com> wrote: > > > From: Marc Morin <m...@emforium.com> > > Subject: Re: Screen Widget Ideas > > To: dev@ofbiz.apache.org > > Date: Saturday, May 15, 2010, 4:11 AM > > 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" <adrian.c...@yahoo.com> > > wrote: > > > > > --- On Fri, 5/14/10, Scott Gray <scott.g...@hotwaxmedia.com> > > 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 > >
