I've tried several ideas to make UI coding easier, one of them being a Groovy screen renderer - where you can mix scripting code with markup. That idea was very close to JSP, and I don't like JSP because I don't like the spaghetti-like mess you end up with when the boundaries between data preparation and presentation are removed.
On the opposite end of the pendulum are the screen widgets - where the boundaries are a little too strict, and sometimes they are an obstacle to getting things done. I've come up with workarounds. One of them was in the example code I supplied in a recent commit message - where I use a screen widget for nothing more than a small reusable script. That's when I came up with this idea, and I believe it is a good compromise. You have good separation of concerns, but you also have the convenience of all of it being in one file. I noticed you've been hard at work on Moqui. It looks like you have a lot of work ahead of you. I'm looking forward to seeing it when it's done. -Adrian --- On Sat, 1/1/11, David E Jones <[email protected]> wrote: > I agree, bouncing around between a lot of files is a pain, > as is having certain files get really large (like the > controller.xml file). Working with apps I always have at > least a controller.xml file, entitymodel.xml file, one or > more services.xml files, one or more simple-method and/or > java files, one or more screens.xml files, one or more > forms.xml files, occasionally a menus.xml file, a > UiLabels.xml file, one or more Data.xml files, and a (insert > favorite euphemism here; "partridge in a pear tree" or > "kitchen sink" are possibilities). > > I say I don't know if this is a good idea, but it might end > up being quite helpful even with the way things are defined > separately in OFBiz. In Moqui I went a different direction > and there is no controller.xml file, everything there is in > the screen definition. Also, the forms and other widgets are > not separate and they are just other widgets built into the > screen (though forms still have names and are can be > referred to from other screens). > > So, anyway, what you propose might be a good step in that > direction without requiring a huge rewrite (like Moqui is... > and I'm feeling the pain of it now that I've moved from > design to implementation!). > > -David > > > On Jan 1, 2011, at 3:35 PM, Adrian Crum wrote: > > > Here's the Jira issue: > > > > https://issues.apache.org/jira/browse/OFBIZ-4090 > > > > I agree that this feature could be abused. It's > another choice a developer can make. > > > > The project I'm working on right now could benefit > from this - I spend way too much time bouncing from file to > file while working on a single screen. In this case, the > separate files are a drawback - not an advantage. > > > > -Adrian > > > > > > --- On Sat, 1/1/11, David E Jones <[email protected]> > wrote: > > > >> From: David E Jones <[email protected]> > >> Subject: Re: Discussion: Support Screen Widget > Namespaces > >> To: [email protected] > >> Date: Saturday, January 1, 2011, 3:20 PM > >> > >> Another approach might be to create a schema that > >> represents the combined schemas of all three and > just > >> include the other XSD files using something like: > >> > >> <xs:include > schemaLocation="widget-screen.xsd"/> > >> > >> As long as they are all in the same directory this > should > >> work fine. You'll probably need to give it a new > root > >> element that allows all of the different screen, > form, etc > >> sub-elements to make it useful. Chances are you'll > run into > >> conflicting element names too. The widgets should > have been > >> done this way from the beginning, ie using various > includes, > >> so that things like the actions element could be > defined in > >> one place and shared between all of the different > types of > >> widgets, instead of having small variations > between each > >> (which developed by lack of checking for > consistency). > >> > >> BTW, I'm not sure if putting different types of > widgets or > >> other things in the same file is a good idea (I > guess only > >> time can tell), but it should be possible. > >> > >> -David > >> > >> > >> On Jan 1, 2011, at 3:10 PM, Adrian Crum wrote: > >> > >>> It's not an issue of conflicting element > names. It's > >> an issue because all of the widget XML files > expect to have > >> only one schema. If you have screens, forms, and > menus all > >> in one file, then you need to support multiple > schemas. > >>> > >>> I have it basically working - I just need to > figure > >> out a validation error. The existing schemas don't > have a > >> TargetNamespace defined, which causes an error. If > I add a > >> TargetNamespace, then I get a different error > saying it was > >> expecting it to be empty. ::scratches head:: > >>> > >>> I'll post a patch on Jira, maybe an XML expert > can > >> figure it out. > >>> > >>> -Adrian > >>> > >>> --- On Sat, 1/1/11, David E Jones <[email protected]> > >> wrote: > >>> > >>>> From: David E Jones <[email protected]> > >>>> Subject: Re: Discussion: Support Screen > Widget > >> Namespaces > >>>> To: [email protected] > >>>> Date: Saturday, January 1, 2011, 2:39 PM > >>>> > >>>> What are the conflicting element names you > are > >> seeing that > >>>> would require the use of namespaces? > >>>> > >>>> -David > >>>> > >>>> > >>>> On Jan 1, 2011, at 10:15 AM, Adrian Crum > wrote: > >>>> > >>>>> The current system of having separate > XML > >> files for > >>>> screens, menus, and forms lends itself > well to > >> some types of > >>>> projects. In some cases, it might be > preferable to > >> have all > >>>> related widgets (screens, forms, menus) in > a > >> single XML > >>>> file. > >>>>> > >>>>> Adding support for multiple widget > types in a > >> single > >>>> file would require a small change to the > widget > >> factory > >>>> code. The "compound widget" XML file would > require > >> the use > >>>> of namespaces - but the added complication > is > >> minimal. > >>>>> > >>>>> Would there be any interest in that? > >>>>> > >>>>> -Adrian > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
