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 <[email protected]> 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 <[email protected]> > 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 <[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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
