Chris,
In my example, VehicleA to C are all the same type of entities, but different
records.
Using auto-fields-entity wouldn't give me the "differentiated field names" I
need, would it?
Jonathon
Chris Howe wrote:
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
