--- 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
