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. > 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. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
