Freemarker macros cannot be nested?

[jonwimp]

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

[David E Jones]

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

[jonwimp]

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

[David E Jones]

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

[jonwimp]

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

[cjhowe]

Look at the examples for auto-fields-entity and auto-fields-service

--- Jonathon -- Improov <[hidden email]> 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
> >>>
> >>>
> >>
> >
> >
>
>

[jonwimp]

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

[cjhowe]

Using form type="mutli" will append _o_row# to the field name couple
that with either auto-field-service or auto-field-entity and I believe
you will get the results or differentiation you're looking for.


--- Jonathon -- Improov <[hidden email]> wrote:

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

[Jacopo Cappellato]

Chris,

I think that Jonathon would like to have one form widget definition for
a list where you can define more than one template according to the
nature of the row.
For example, if you have a list with OrderItems and OrderItemAdjustments
intermixed, the form should be able to display the content of each row
in the proper way.
Right now this is possible only using the use-when attribute, but the
form definition will be very difficult to read (especially if you have
many formats).
I agree with Jonathon that this would be a nice improvement (with it,
forms could be used to render nice reports) but I'm not sure about the
best way to model it.

Jacopo


Chris Howe wrote:

> Using form type="mutli" will append _o_row# to the field name couple
> that with either auto-field-service or auto-field-entity and I believe
> you will get the results or differentiation you're looking for.
>
>
> --- Jonathon -- Improov <[hidden email]> wrote:
>
>> 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 <[hidden email]> 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
>>>
>>

[Jacopo Cappellato]

Jonathon,

you may be interested in the patches that I've attached to the issue
OFBIZ-1075.
I did some successful tests in my box using (in a widget list form) the
"position" attribute to define different sets of fields and the
"use-when" attribute to use the right one; the condition (a boolean) is
set in the form's <row-actions> element.
Of course they can also be used to render in list subtotals or group
headers (as you can see in the picture attached to Jira).
I hope to get positive feedback on my work and then commit it; I plan to
work on some enhancements (not big changes, everything in the 'spirit'
of the widgets) to the form widgets like this one in the future.

Jacopo

Jacopo Cappellato wrote:

> Chris,
>
> I think that Jonathon would like to have one form widget definition for
> a list where you can define more than one template according to the
> nature of the row.
> For example, if you have a list with OrderItems and OrderItemAdjustments
> intermixed, the form should be able to display the content of each row
> in the proper way.
> Right now this is possible only using the use-when attribute, but the
> form definition will be very difficult to read (especially if you have
> many formats).
> I agree with Jonathon that this would be a nice improvement (with it,
> forms could be used to render nice reports) but I'm not sure about the
> best way to model it.
>
> Jacopo
>
>
> Chris Howe wrote:
>> Using form type="mutli" will append _o_row# to the field name couple
>> that with either auto-field-service or auto-field-entity and I believe
>> you will get the results or differentiation you're looking for.
>>
>>
>> --- Jonathon -- Improov <[hidden email]> wrote:
>>
>>> 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 <[hidden email]> 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
>>>>
>>>