Look at the examples for auto-fields-entity and auto-fields-service --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
> My biggest problem with Widget Forms is that I'm unable to reuse > certain chunks of UIs. > > Example here. > > Say I have one big form with 3 sets of similar fields. Say the sets > are named VehicleA, VehicleB > and VehicleC. Each set has fields Manufacturer, Model, Year, and so > on. In Widget Forms, I need to > manually key in field names VehicleA_Manufacturer, VehicleB_Year, > etc. In Freemarker macros, well, > I'm sure you get the picture. > > Or am I missing something in Widget Forms? > > Another big stumbling block is the inability to put blocks of UIs > under a conditional, like > <condition> in Widget Screens. > > Any help, before I dive headlong into Freemarker macros? > > Frankly, I just wanted a quick and dirty and cheap way to do things > in UI. At first, I thought it > was Widget Forms. But after some time, Widget Forms' simplicity kinda > got in the way and made it > difficult rather than simple. Layouts are imprecise and cannot be > arranged to flow correctly. > Fields cannot be neatly grouped together without breaking layout. And > the list goes on. > > Things were fine when I only had to do small forms that dealt with > only a single (or at most a > few) type of record. And then, clients and end-users started asking > for user-friendly forms that > flowed with their workflow, not with the data structure. > > And of course, with Ajax thrown in, all hell broke loose. > > Jonathon > > David E Jones wrote: > > > > In general the issue is: what is(are) the problem(s) this is meant > to > > solve? > > > > Here are some comments on the stuff I saw in the opentaps mailing > list > > discussion about this: > > > > Extending the form widget is really pretty easy, and most of the > time > > really pretty unnecessary as long as someone on the team really > knows > > how to use it and CSS well. > > > > So IMO for OFBiz this sort of practice would not be of much value. > Their > > macro library will likely become bloated and difficult to organize > and > > structure, and therefore difficult to use, and with what was > described > > it doesn't look like they are getting a lot of code savings over > > straight up FTL templates, but they ARE sacrificing some ease in > > customization and making it much more difficult to reskin for > custom > > sites. So no, I don't think we'd want to do anything like this in > OFBiz. > > > > Of course, that's just my first glance opinion based on previous > > experience, mostly with JSP tag libs and other such things. Without > > > really trying it out and finding out what sorts of problems the > form > > widgets is not helping with, I couldn't say for sure. > > > > -David > > > > > > Jonathon -- Improov wrote: > >> What's the main reason against that approach? > >> > >> I think using Freemarker macros can allow for more reusable chunks > of > >> UIs than Widget Forms can. And of course, using Freemarker means > you > >> can make your UIs as pretty or plain as you want, HTML/CSS limits > are > >> the limits here. > >> > >> One problem with this approach I can see: I'm missing the > convenient > >> <entity-options>. > >> > >> Jonathon > >> > >> David E Jones wrote: > >>> > >>> I think the opentaps guys (Si Chen, Leon Torres, Chris Libery, > etc) > >>> have worked on something along these lines. > >>> > >>> I'm not a huge fan of this approach (ie a generic library of > macros > >>> as a form widget replacement or to use in ecommerce > applications), > >>> but they have been working on it and I imagine have at least had > some > >>> success with it. > >>> > >>> -David > >>> > >>> > >>> Jonathon -- Improov wrote: > >>>> Hi to all of you out there having fun with freemarker macros! > >>>> > >>>> Just to confirm, freemarker macros cannot be nested? > >>>> > >>>> Has anybody built any base suite of macros that can do most of > what > >>>> Widget Forms can do? > >>>> > >>>> Jonathon > >>> > >>> > >> > > > > > >
