From: "Adrian Crum" <adrian.c...@yahoo.com>
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
This makes sense indeed, I can't see any drawbacks but if you need to jump from another group of screens in Party for instance. I
think they are pros and cons but it's worth it.
Jacques
--- 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.
