Re: [FM3] Continuing Spring MVC Form Directives Support

[Woonsan Ko <wo...@apache.org>]

Hi,

Just for heads-up, I've come to an end of the first development
iteration to support spring functions and directives. See the "Spring"
section in FM3-CHANGE-LOG.txt for detail.
This is not near perfect yet so I will spend more time improving (unit
or integration) tests and finding/fixing problems.
Please feel free to review and test.

Cheers,

Woonsan

On Tue, Jan 2, 2018 at 11:36 PM, Woonsan Ko <wo...@apache.org> wrote:
> Hi,
>
> It has been a long time since my last commit to support spring mvc
> functions/directives (FREEMARKER-55).
> Today, I've opened a pull request, containing an initial form related
> work (only form:form and form:input directives for now, but those are
> parts of the crucial basement):
> - https://github.com/apache/incubator-freemarker/pull/41
>
> Please feel free to take a look and let me know if you have any
> comments or remarks.
>
> Some pointers:
> - Initially I tried to leverage dynamic varargs for almost every html
> attribute, but I ended up defining each available attribute as member
> like Spring taglibs do, which seems clearer in both argument layout
> and maintenance.
> - Arguments for html attributes are kind of inherited from base
> classes such as AbstractHtmlElementTemplateDirectiveModel. I ended up
> merging named arg list in child directives by accessing static
> members, which is not totally clean - static members are visible
> anywhere, but that's what I think is the best for now.
> - spring:* tags are mapped to "spring.*" models, whereas form:* tags
> are mapped to "spring.form.*" models. I didn't want to expose "form"
> model separately in a higher level. I found out it's convenient to
> write <#assign form=spring.form /> in order to use <@form.input .../>
> instead of <@spring.form.input .../>.
> - The other (remaining) tasks seem to be relatively more
> straightforward: other inputs, button, textarea, select, etc.
>
> I'll probably merge the PR by myself in a day or two and continue with
> other directives while being willing to hear any feedback and
> suggestions.
>
> Kind regards,
>
> Woonsan

Re: [FM3] Continuing Spring MVC Form Directives Support

[Daniel Dekany <dd...@apache.org>]

Tuesday, July 24, 2018, 1:30:01 AM, Woonsan Ko wrote:

> Hi,
>
> Just for heads-up, I've come to an end of the first development
> iteration to support spring functions and directives. See the "Spring"
> section in FM3-CHANGE-LOG.txt for detail.
> This is not near perfect yet so I will spend more time improving (unit
> or integration) tests and finding/fixing problems.
> Please feel free to review and test.

I will, eventually. And thanks for all the work put into this! (I was
quite inactive in the recent... months. Will see when can I return to
continue FM3, and the new FM2 release.)

> Cheers,
>
> Woonsan
>
> On Tue, Jan 2, 2018 at 11:36 PM, Woonsan Ko <wo...@apache.org> wrote:
>> Hi,
>>
>> It has been a long time since my last commit to support spring mvc
>> functions/directives (FREEMARKER-55).
>> Today, I've opened a pull request, containing an initial form related
>> work (only form:form and form:input directives for now, but those are
>> parts of the crucial basement):
>> - https://github.com/apache/incubator-freemarker/pull/41
>>
>> Please feel free to take a look and let me know if you have any
>> comments or remarks.
>>
>> Some pointers:
>> - Initially I tried to leverage dynamic varargs for almost every html
>> attribute, but I ended up defining each available attribute as member
>> like Spring taglibs do, which seems clearer in both argument layout
>> and maintenance.
>> - Arguments for html attributes are kind of inherited from base
>> classes such as AbstractHtmlElementTemplateDirectiveModel. I ended up
>> merging named arg list in child directives by accessing static
>> members, which is not totally clean - static members are visible
>> anywhere, but that's what I think is the best for now.
>> - spring:* tags are mapped to "spring.*" models, whereas form:* tags
>> are mapped to "spring.form.*" models. I didn't want to expose "form"
>> model separately in a higher level. I found out it's convenient to
>> write <#assign form=spring.form /> in order to use <@form.input .../>
>> instead of <@spring.form.input .../>.
>> - The other (remaining) tasks seem to be relatively more
>> straightforward: other inputs, button, textarea, select, etc.
>>
>> I'll probably merge the PR by myself in a day or two and continue with
>> other directives while being willing to hear any feedback and
>> suggestions.
>>
>> Kind regards,
>>
>> Woonsan
>

-- 
Thanks,
 Daniel Dekany