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 <d...@me.com> 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 <d...@me.com> >> wrote: >>> >>>> From: David E Jones <d...@me.com> >>>> Subject: Re: Discussion: Support Screen Widget >> Namespaces >>>> To: dev@ofbiz.apache.org >>>> 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 <d...@me.com> >>>> wrote: >>>>> >>>>>> From: David E Jones <d...@me.com> >>>>>> Subject: Re: Discussion: Support Screen >> Widget >>>> Namespaces >>>>>> To: dev@ofbiz.apache.org >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
