In case anyone is wondering what the advantage is to doing things this way, I can use the Party Manager as an example.
The Party Manager application is huge. For the most part, having all screens in one file, all forms in one file, all menus in one file, etc makes sense. But in an application that size, those files have become very big and monolithic. That slows down development because a lot of time is spent going from file to file and searching through the file for the bit of information you need. There are portions of the Party Manager application that are somewhat atomic and lend themselves well to being separated out. Let's use the Party Roles screen as an example. The Party Roles screen contains 1 screen widget (not including the decorators), and 4 form widgets. The screen widget is defined in PartyScreens.xml - which contains about 35 screen widgets. The form widgets are defined in PartyForms.xml - which contains around 50 form widgets. We *could* put those 4 form widgets in their own form widget file, but then we would still have an additional file to work with. The Party Roles screen requires 4 requests and 1 view map. Those requests and view map are in the controller.xml file - which is 1338 lines long. Again, we *could* put those requests and view in a separate file, but then we would still have an additional file to work with. Here is how the Party Roles screen artifacts could be organized in the proposed compound widget file: We could create a file called PartyRole.xml, and then put the 1 screen widget, 4 form widgets, 4 requests, and 1 view map in that file. All Party Role UI-related artifacts are now in one place where they are easy to find. The same process could be repeated for Party Relationships. -Adrian --- On Sun, 1/2/11, Adrian Crum <adrian.c...@yahoo.com> wrote: > Okay, I got the XML parsing errors > fixed. It required new schemas. > > If we want to add this feature to the project, we will need > two versions of some schemas (all screen widget xsd files, > simple-methods.xsd and site-conf.xsd). The new versions > could include a version number in the file name, like > widget-screen-v2.xsd as an example. > > Adding the version number to the xsd file name also solves > another problem - currently all versions of OFBiz are > referencing a single xsd file version. In the future, as xsd > files are changed, they could be given a new version number > and the dependent XML files would be updated to reference > them. Or we could have the version number in the url and put > the new schemas in the new url. > > David suggested using schema includes to share schemas > (like for widget actions). This change could be a first step > in that direction - because the new schemas will have their > own namespace. > > I have updated the Jira issue with a new patch so everyone > can take a look: > > https://issues.apache.org/jira/browse/OFBIZ-4090 > > Comments and suggestions are welcome! > > -Adrian > > --- On Sun, 1/2/11, Adrian Crum <adrian.c...@yahoo.com> > wrote: > > --- On Sat, 1/1/11, David E Jones > > <d...@me.com> > > wrote: > > > In Moqui I went a different direction > > > and there is no controller.xml file, everything > there > > is in > > > the screen definition. > > > > We could do that in OFBiz too. Since the > controller.xml > > file supports the <include> element, it would be > a > > simple matter to add a <controller> element to > the > > compound screen widget file, and then use the > controller's > > <include> element to include the compound > screen > > widget file. > > > > The more I think about it, the more I like the idea. > > > > > >
