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