Discussion: Support Screen Widget Namespaces

[Adrian Crum-2]

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




     

[David E. Jones-2]

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

[Adrian Crum-2]

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

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: Support Screen Widget Namespaces
> To: [hidden email]
> 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
> >
> >
> >
> >
> >
>
>

     

[David E. Jones-2]

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 <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Discussion: Support Screen Widget Namespaces
>> To: [hidden email]
>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: Support Screen Widget Namespaces
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >
> >> From: David E Jones <[hidden email]>
> >> Subject: Re: Discussion: Support Screen Widget
> Namespaces
> >> To: [hidden email]
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

     

[David E. Jones-2]

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 <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Discussion: Support Screen Widget Namespaces
>> To: [hidden email]
>> 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 <[hidden email]>
>> wrote:
>>>
>>>> From: David E Jones <[hidden email]>
>>>> Subject: Re: Discussion: Support Screen Widget
>> Namespaces
>>>> To: [hidden email]
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> >> From: David E Jones <[hidden email]>
> >> Subject: Re: Discussion: Support Screen Widget
> Namespaces
> >> To: [hidden email]
> >> 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 <[hidden email]>
> >> wrote:
> >>>
> >>>> From: David E Jones <[hidden email]>
> >>>> Subject: Re: Discussion: Support Screen
> Widget
> >> Namespaces
> >>>> To: [hidden email]
> >>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

     

[Scott Gray-2]

I've been playing around with Jelly (http://commons.apache.org/jelly/) lately and it might be worth taking a look at while you're on this train of thought.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 2/01/2011, at 8:14 PM, Adrian Crum wrote:

> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>>
>>>> From: David E Jones <[hidden email]>
>>>> Subject: Re: Discussion: Support Screen Widget
>> Namespaces
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> From: David E Jones <[hidden email]>
>>>>>> Subject: Re: Discussion: Support Screen
>> Widget
>>>> Namespaces
>>>>>> To: [hidden email]
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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



     

[Adrian Crum-2]

Thanks Scott! Having a Jelly screen renderer might be worthwhile, but it's beyond my current availability. I was looking for a way to make a few small changes in the existing screen widgets to make application development faster.

-Adrian

--- On Sun, 1/2/11, Scott Gray <[hidden email]> wrote:

> I've been playing around with Jelly
> (http://commons.apache.org/jelly/) lately and it might
> be worth taking a look at while you're on this train of
> thought.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 2/01/2011, at 8:14 PM, Adrian Crum wrote:
>
> > 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 <[hidden email]>
> 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 <[hidden email]>
> >> wrote:
> >>>
> >>>> From: David E Jones <[hidden email]>
> >>>> Subject: Re: Discussion: Support Screen
> Widget
> >> Namespaces
> >>>> To: [hidden email]
> >>>> 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
> <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> From: David E Jones <[hidden email]>
> >>>>>> Subject: Re: Discussion: Support
> Screen
> >> Widget
> >>>> Namespaces
> >>>>>> To: [hidden email]
> >>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

     

[David E. Jones-2]

On Jan 2, 2011, at 10:55 AM, Adrian Crum 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.

You're thinking of having the main controller.xml file include every screen (or combined widget, rather) file that does this sort of thing? It's a little cumbersome, but maybe less so that the current often large single controller.xml files.

-David

[Adrian Crum-2]

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

> On Jan 2, 2011, at 10:55 AM, Adrian Crum 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.
>
> You're thinking of having the main controller.xml file
> include every screen (or combined widget, rather) file that
> does this sort of thing? It's a little cumbersome, but maybe
> less so that the current often large single controller.xml
> files.

Right - the application that contains the compound widget file would have the include in its controller.xml file.

-Adrian



     

[Erwan de FERRIERES]

Le 02/01/2011 10:05, Scott Gray a écrit :
> I've been playing around with Jelly (http://commons.apache.org/jelly/) lately and it might be worth taking a look at while you're on this train of thought.
>
> Regards
> Scott

>

Jelly is also used in Hudson :
http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson

There is a subsection called Writing Jelly


Cheers,

--
Erwan de FERRIERES
www.nereide.biz