How would we use dependency injection in the screen widgets? -Adrian
--- On Sat, 5/15/10, Marc Morin <[email protected]> wrote: > Google Guice seems really interesting > approach to handling "factories". Anyone had any > experience with it? > > Marc > ----- "Adrian Crum" <[email protected]> > wrote: > > > Marc, > > > > Do you have any thoughts on the first two ideas I > proposed? > > > > -Adrian > > > > --- On Sat, 5/15/10, Marc Morin <[email protected]> > wrote: > > > > > From: Marc Morin <[email protected]> > > > Subject: Re: Screen Widget Ideas > > > To: [email protected] > > > 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" <[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 > > > >
