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 >
