Discussion: Compound Screen Widget Files (was: Discussion: Support Screen Widget Namespaces)

[Adrian Crum-2]

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 <[hidden email]> wrote:

> --- On Sat, 1/1/11, David E Jones
> <[hidden email]>
> 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.

     

[David E. Jones-2]

About the schema includes: they don't need to have separate namespaces for that. Actually, you could use includes to avoid the use of namespaces by having a new single schema file that includes all the others you want to use, and then have the combined widget XML files refer to that new schema file.

-David


On Jan 2, 2011, at 5:31 PM, Adrian Crum 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 <[hidden email]> wrote:
>> --- On Sat, 1/1/11, David E Jones
>> <[hidden email]>
>> 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.
>
>
>
>
>

[Adrian Crum-2]

I tried that and I couldn't get it to work. :-(

-Adrian

--- On Sun, 1/2/11, David E Jones <[hidden email]> wrote:

> About the schema includes: they don't need to have separate
> namespaces for that. Actually, you could use includes to
> avoid the use of namespaces by having a new single schema
> file that includes all the others you want to use, and then
> have the combined widget XML files refer to that new schema
> file.
>
> -David
>
>
> On Jan 2, 2011, at 5:31 PM, Adrian Crum 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 <[hidden email]>
> wrote:
> >> --- On Sat, 1/1/11, David E Jones
> >> <[hidden email]>
> >> 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.
> >
> >
> >
> >
> >
>
>

     

[Adrian Crum-2]

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 <[hidden email]> 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 <[hidden email]>
> wrote:
> > --- On Sat, 1/1/11, David E Jones
> > <[hidden email]>
> > 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.
>
>
>
>
>      
>

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>> > --- On Sat, 1/1/11, David E Jones
>> > <[hidden email]>
>> > 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.
>>
>>
>>
>>
>>
>>
>
>
>
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Adrian Crum" <[hidden email]>
>> 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.

Ha also I like to search in *een* files and *form* files to narrow the targets (specially in custom projects, but not only)

Jacques

> Jacques
>
>>
>> --- On Sun, 1/2/11, Adrian Crum <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>> > --- On Sat, 1/1/11, David E Jones
>>> > <[hidden email]>
>>> > 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>