Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Thu, Sep 14, 2017 at 5:09 AM, Daniel Dekany  wrote:
> Thursday, September 14, 2017, 4:15:04 AM, Woonsan Ko wrote:
>
> [snip]
 And, I'd like to ask about this example:

 ${user.id!}

 The reason why I had to use ?string built-in was that user.id returns
 a TemplateNumberModel, while the function is expecting a string
 argument.
>>>
>>> But do we really have to do that conversion? MessageFormat allows
>>> Object parameters, also it has its own mini template language, which
>>> can, among others, format numbers. I don't think we should interfere
>>> with that, at least not by default.
>>
>> The example is about spring.url function, not spring.message function.
>
> Ugh... sorry. So then the situation is different. We should convert
> automatically to string, but definitely not with
> Environment.formatXxx, as that formats for human audience, so you can
> end up with `id=1,234,567` instead of `id=1234567`. Number formatted
> for URL-s should always follow computer format. For boolean it should
> be clearly true/false (so yet again we don't use the current boolean
> format).
>
> Temporal values is a problem, because they have no universally
> accepted computer format. Perhaps we should format them according to
> the ISO standard (with an XSD compliant variation of it). _DateUtils
> can do that. But for timestamps, seconds or millis since the epoch is
> also often used. I'm not sure if there's a convention in the
> Java(/Spring) ecosystem that prevalent enough. Probably we should just
> throw a helpful exception in which we tell the user to format the
> thing manually, for example with ?long or ?string.iso or ?string.xs.
>
> Then there are lists and maps (sequences and hashes as FM calls
> them... until I change it in FM3). I assume those should be just
> errors. (I don't know if the JSP taglib has some speciality for them.
> For example for lists, I would think that if I write `tag={tag}` and
> the value is a list, then they should generate
> `tag=val1=val2=valN`.)

Thanks again for the insights!
I've made a new pull request to address those:
- https://github.com/apache/incubator-freemarker/pull/36

The spring.url function now converts only TemplateStringModel,
TemplateNumberModel and TemplateBooleanModel and throw exception for
other types with an error message.
AFAIK, JSP taglib doesn't do much for list or map. It probably uses
#toString(). And, since both  and  in
 and  accepts only String parameter name/value
pair, I don't think there's anything more.

Please take another look at it.

Kind regards,

Woonsan

>
>> The former one takes strings only for both param name and param value
>> ( tags inside  tag). The latter one takes
>> Object array, single object or comma separated string
>> ( and ).
>> In spring.url function, it should be more convenient if we can take
>> TemplateNumberModel named parameters without '?string' for instance.
>>
>>>
 But, if there's a way to convert a TemplateNumberModel to a string,
 then I think the function might be more convenient without having to
 use ?string.
 Do you think if there's a way to improve this (allowing somethings
 like TemplateNumberModel in this kind of string-expected values), or
 ?string is a good way? Or any other options?
>>>
>>> If those still have to be strings, then surely we don't want users to
>>> write ?string everywhere, because that's repetative and so we should
>>> do it instead. I have added Environment.formatToPlainText; you can use
>>> that for now in case the parameter is not a TemplateStringModel. (I
>>> guess this method should be backported to FM2 as well.)
>>
>> Thanks for the tip! I've updated the PR to use
>> Environment.formatToPlainText in UrlFunction as well if a parameter
>> value is not TemplateStringModel.
>>
>>>
>>> BTW, I wonder that if the messages contains HTML, and hence it's
>>> printed by FreeMarker without escaping, what ensures that the
>>> substituted parameters are HTML-escaped. That's a security issue, so
>>> we must find an answer to that, when we will support returning
>>> MarkupOutputModel-s.
>>
>> Good point. I have assumed that developers need to escape the result
>> by themselves, but yes, we will need more considerations with
>> examples.
>>
>> Kind regards,
>>
>> Woonsan
>>
>>>
 Kind regards,

 Woonsan

>
>> Thanks,
>>
>> Woonsan
>>
>>>
>>> Cheers,
>>>
>>> Woonsan
>>>

> (ref:
> https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl)
>
> Still need to add an example using 'message' named parameter.
>
> Regards,
>
> Woonsan
>
>>
>>> look at `spring.message("foo")`, I think you would intuitively think
>>> that it prints the "foo" message. As of the others, I guess we don't
>>> need "text" as you can write 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Wed, Sep 13, 2017 at 2:28 PM, Daniel Dekany  wrote:
> Wednesday, September 13, 2017, 6:48:25 PM, Woonsan Ko wrote:
>
>> On Wed, Sep 13, 2017 at 5:50 AM, Daniel Dekany  wrote:
>>> Wednesday, September 13, 2017, 4:20:35 AM, Woonsan Ko wrote:
>>>
>>> [snip]
 I've proposed a PR for tags defined in spring.tld for now:
 https://github.com/apache/incubator-freemarker/pull/34
 I'll continue to replace tags in form.tld.
>>>
>>> Thanks, looks good, I have merged it!
>>>
>>> One day (probably when you feel it's already polished) I will go
>>> through it thoroughly. For now I have more like skimmed through it. So
>>> tell me if I should look at something more closely, like you have some
>>> doubts there. Some random remarks:
>>>
>>> - AbstractSpringTemplateDirectiveModel and its subclasses probably
>>>   shouldn't be public. (Also executeInternal probably should be
>>>   protected.) Generally, we should avoid exposing things as published
>>>   API-s, because they all become backward compatibility constraints.
>>>   (It's major difficulty with libraries that thousands of projects
>>>   depend on, as I have learned the hard way with FM2...)
>>>
>>> - final MessageSourceResolvable messageResolvable = (messageResolvableModel 
>>> != null)
>>>   ? (MessageSourceResolvable) 
>>> objectWrapperAndUnwrapper.unwrap(messageResolvableModel) : null;
>>>
>>>   You can have ClassCastException here instead of a TemplateException
>>>   that explains the higher level problem. Certainly you should
>>>   introduce and then use something like:
>>>   CallableUtil.getAndUnwrapArgument(..., MessageSourceResolvable.class, ...)
>>>
>>> - Things similar to this:
>>>
>>> <#assign expression="T(java.lang.Math).max(12.34, 56.78)" />
>>> ${spring.eval(expression)}
>>>
>>>   or this:
>>>
>>> <#assign pathInfo="http://freemarker.org/docs/index.html; />
>>> Apache FreeMarker Manual
>>>
>>>   I think they are more readable (for most of us anyway) without the
>>>   intermediate variable that's use only once. Like:
>>>
>>> ${spring.eval("T(java.lang.Math).max(12.34, 
>>> 56.78)")}
>>
>> I've proposed a new PR with the changes for all that you suggested
>> above. Good points! Thanks for the great suggestions!
>
> I think "getOptionalArgumentAndUnwrap" ("get option  and ...")
> sounds better in English than "getOptionalAndUnwrapArgument".
>
> Also, when JavaDoc-ing this new method, it should just refer to
> castArgumentValue for the description of the arguments, just like the
> dozens of other methods in CallableUtils. Yes, it's less convenient
> for the user, but it's much less likely for the JavaDocs to go out of
> sync with reality if it's "normalized".
>
> I have just noticed that `gradlew aggregateJavadoc` runs into some
> JavaDoc errors that `gradlew javadoc` doesn't. Please take a look. (I
> will switch over to aggregateJavadoc on Travis, or run both there...)

I've fixed those issues and updated the PR:
- https://github.com/apache/incubator-freemarker/pull/35

>
>> And, I'd like to ask about this example:
>>
>> ${user.id!}
>>
>> The reason why I had to use ?string built-in was that user.id returns
>> a TemplateNumberModel, while the function is expecting a string
>> argument.
>
> But do we really have to do that conversion? MessageFormat allows
> Object parameters, also it has its own mini template language, which
> can, among others, format numbers. I don't think we should interfere
> with that, at least not by default.

The example is about spring.url function, not spring.message function.
The former one takes strings only for both param name and param value
( tags inside  tag). The latter one takes
Object array, single object or comma separated string
( and ).
In spring.url function, it should be more convenient if we can take
TemplateNumberModel named parameters without '?string' for instance.

>
>> But, if there's a way to convert a TemplateNumberModel to a string,
>> then I think the function might be more convenient without having to
>> use ?string.
>> Do you think if there's a way to improve this (allowing somethings
>> like TemplateNumberModel in this kind of string-expected values), or
>> ?string is a good way? Or any other options?
>
> If those still have to be strings, then surely we don't want users to
> write ?string everywhere, because that's repetative and so we should
> do it instead. I have added Environment.formatToPlainText; you can use
> that for now in case the parameter is not a TemplateStringModel. (I
> guess this method should be backported to FM2 as well.)

Thanks for the tip! I've updated the PR to use
Environment.formatToPlainText in UrlFunction as well if a parameter
value is not TemplateStringModel.

>
> BTW, I wonder that if the messages contains HTML, and hence it's
> printed by FreeMarker without escaping, what ensures that the
> substituted parameters are HTML-escaped. That's a security issue, so
> we must find an answer to 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Wednesday, September 13, 2017, 6:48:25 PM, Woonsan Ko wrote:

> On Wed, Sep 13, 2017 at 5:50 AM, Daniel Dekany  wrote:
>> Wednesday, September 13, 2017, 4:20:35 AM, Woonsan Ko wrote:
>>
>> [snip]
>>> I've proposed a PR for tags defined in spring.tld for now:
>>> https://github.com/apache/incubator-freemarker/pull/34
>>> I'll continue to replace tags in form.tld.
>>
>> Thanks, looks good, I have merged it!
>>
>> One day (probably when you feel it's already polished) I will go
>> through it thoroughly. For now I have more like skimmed through it. So
>> tell me if I should look at something more closely, like you have some
>> doubts there. Some random remarks:
>>
>> - AbstractSpringTemplateDirectiveModel and its subclasses probably
>>   shouldn't be public. (Also executeInternal probably should be
>>   protected.) Generally, we should avoid exposing things as published
>>   API-s, because they all become backward compatibility constraints.
>>   (It's major difficulty with libraries that thousands of projects
>>   depend on, as I have learned the hard way with FM2...)
>>
>> - final MessageSourceResolvable messageResolvable = (messageResolvableModel 
>> != null)
>>   ? (MessageSourceResolvable) 
>> objectWrapperAndUnwrapper.unwrap(messageResolvableModel) : null;
>>
>>   You can have ClassCastException here instead of a TemplateException
>>   that explains the higher level problem. Certainly you should
>>   introduce and then use something like:
>>   CallableUtil.getAndUnwrapArgument(..., MessageSourceResolvable.class, ...)
>>
>> - Things similar to this:
>>
>> <#assign expression="T(java.lang.Math).max(12.34, 56.78)" />
>> ${spring.eval(expression)}
>>
>>   or this:
>>
>> <#assign pathInfo="http://freemarker.org/docs/index.html; />
>> Apache FreeMarker Manual
>>
>>   I think they are more readable (for most of us anyway) without the
>>   intermediate variable that's use only once. Like:
>>
>> ${spring.eval("T(java.lang.Math).max(12.34, 
>> 56.78)")}
>
> I've proposed a new PR with the changes for all that you suggested
> above. Good points! Thanks for the great suggestions!

I think "getOptionalArgumentAndUnwrap" ("get option  and ...")
sounds better in English than "getOptionalAndUnwrapArgument".

Also, when JavaDoc-ing this new method, it should just refer to
castArgumentValue for the description of the arguments, just like the
dozens of other methods in CallableUtils. Yes, it's less convenient
for the user, but it's much less likely for the JavaDocs to go out of
sync with reality if it's "normalized".

I have just noticed that `gradlew aggregateJavadoc` runs into some
JavaDoc errors that `gradlew javadoc` doesn't. Please take a look. (I
will switch over to aggregateJavadoc on Travis, or run both there...)

> And, I'd like to ask about this example:
>
> ${user.id!}
>
> The reason why I had to use ?string built-in was that user.id returns
> a TemplateNumberModel, while the function is expecting a string
> argument.

But do we really have to do that conversion? MessageFormat allows
Object parameters, also it has its own mini template language, which
can, among others, format numbers. I don't think we should interfere
with that, at least not by default.

> But, if there's a way to convert a TemplateNumberModel to a string,
> then I think the function might be more convenient without having to
> use ?string.
> Do you think if there's a way to improve this (allowing somethings
> like TemplateNumberModel in this kind of string-expected values), or
> ?string is a good way? Or any other options?

If those still have to be strings, then surely we don't want users to
write ?string everywhere, because that's repetative and so we should
do it instead. I have added Environment.formatToPlainText; you can use
that for now in case the parameter is not a TemplateStringModel. (I
guess this method should be backported to FM2 as well.)

BTW, I wonder that if the messages contains HTML, and hence it's
printed by FreeMarker without escaping, what ensures that the
substituted parameters are HTML-escaped. That's a security issue, so
we must find an answer to that, when we will support returning
MarkupOutputModel-s.

> Kind regards,
>
> Woonsan
>
>>
>>> Thanks,
>>>
>>> Woonsan
>>>

 Cheers,

 Woonsan

>
>> (ref:
>> https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl)
>>
>> Still need to add an example using 'message' named parameter.
>>
>> Regards,
>>
>> Woonsan
>>
>>>
 look at `spring.message("foo")`, I think you would intuitively think
 that it prints the "foo" message. As of the others, I guess we don't
 need "text" as you can write ${spring.message("foo")!'default'}, nor
 do we need the xxxEscape parameters, as we have HTML auto-escaping and
 `spring.message("foo")?jsString`.
>>>
>>> Oh, cool! I didn't know 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Wed, Sep 13, 2017 at 5:50 AM, Daniel Dekany  wrote:
> Wednesday, September 13, 2017, 4:20:35 AM, Woonsan Ko wrote:
>
> [snip]
>> I've proposed a PR for tags defined in spring.tld for now:
>> https://github.com/apache/incubator-freemarker/pull/34
>> I'll continue to replace tags in form.tld.
>
> Thanks, looks good, I have merged it!
>
> One day (probably when you feel it's already polished) I will go
> through it thoroughly. For now I have more like skimmed through it. So
> tell me if I should look at something more closely, like you have some
> doubts there. Some random remarks:
>
> - AbstractSpringTemplateDirectiveModel and its subclasses probably
>   shouldn't be public. (Also executeInternal probably should be
>   protected.) Generally, we should avoid exposing things as published
>   API-s, because they all become backward compatibility constraints.
>   (It's major difficulty with libraries that thousands of projects
>   depend on, as I have learned the hard way with FM2...)
>
> - final MessageSourceResolvable messageResolvable = (messageResolvableModel 
> != null)
>   ? (MessageSourceResolvable) 
> objectWrapperAndUnwrapper.unwrap(messageResolvableModel) : null;
>
>   You can have ClassCastException here instead of a TemplateException
>   that explains the higher level problem. Certainly you should
>   introduce and then use something like:
>   CallableUtil.getAndUnwrapArgument(..., MessageSourceResolvable.class, ...)
>
> - Things similar to this:
>
> <#assign expression="T(java.lang.Math).max(12.34, 56.78)" />
> ${spring.eval(expression)}
>
>   or this:
>
> <#assign pathInfo="http://freemarker.org/docs/index.html; />
> Apache FreeMarker Manual
>
>   I think they are more readable (for most of us anyway) without the
>   intermediate variable that's use only once. Like:
>
> ${spring.eval("T(java.lang.Math).max(12.34, 
> 56.78)")}

I've proposed a new PR with the changes for all that you suggested
above. Good points! Thanks for the great suggestions!
And, I'd like to ask about this example:

${user.id!}

The reason why I had to use ?string built-in was that user.id returns
a TemplateNumberModel, while the function is expecting a string
argument.
But, if there's a way to convert a TemplateNumberModel to a string,
then I think the function might be more convenient without having to
use ?string.
Do you think if there's a way to improve this (allowing somethings
like TemplateNumberModel in this kind of string-expected values), or
?string is a good way? Or any other options?

Kind regards,

Woonsan

>
>> Thanks,
>>
>> Woonsan
>>
>>>
>>> Cheers,
>>>
>>> Woonsan
>>>

> (ref:
> https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl)
>
> Still need to add an example using 'message' named parameter.
>
> Regards,
>
> Woonsan
>
>>
>>> look at `spring.message("foo")`, I think you would intuitively think
>>> that it prints the "foo" message. As of the others, I guess we don't
>>> need "text" as you can write ${spring.message("foo")!'default'}, nor
>>> do we need the xxxEscape parameters, as we have HTML auto-escaping and
>>> `spring.message("foo")?jsString`.
>>
>> Oh, cool! I didn't know we have ?jsString. Perfect.
>>
>>>
>
> Something that would be interesting if the spring.message function can
> somehow tell if a message is plain text or HTML. Like you can
> configure which messages are HTML on name patterns (or a content
> pattern, like all HTML values start with ""). After all, without
> such a rule, how do the developers themselves know if a message should
> be HTML or plain text. Hopefully the have some exact policy for that.
> If spring.message knows that rule too, then for HTML messages it
> should return a TemplateMarkupOutputModel instead of a string, so it
> will be automatically non-escaped. Then people can just write
> ${spring.message("foo")} without worrying about `?noEsc`. And then we
> certainly don't need the directive "overload" either.

 As far as I know, MessageTag extends HtmlEscapingAwareTag which has
 the following javadoc:

  * Provides a "htmlEscape" property for explicitly specifying 
 whether to
  * apply HTML escaping. If not set, a page-level default (e.g. from the
  * HtmlEscapeTag) or an application-wide default (the 
 "defaultHtmlEscape"
  * context-param in {@code web.xml}) is used.
>>>
>>> So then it seems we indeed need some spring library configuration
>>> parameter that associates an output format (as in
>>> http://freemarker.org/docs/dgui_misc_autoescaping.html) to each
>>> message, based on patterns. By default everything should be just plain
>>> text, to be on the safe side (i.e., 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Wednesday, September 13, 2017, 4:20:35 AM, Woonsan Ko wrote:

[snip]
> I've proposed a PR for tags defined in spring.tld for now:
> https://github.com/apache/incubator-freemarker/pull/34
> I'll continue to replace tags in form.tld.

Thanks, looks good, I have merged it!

One day (probably when you feel it's already polished) I will go
through it thoroughly. For now I have more like skimmed through it. So
tell me if I should look at something more closely, like you have some
doubts there. Some random remarks:

- AbstractSpringTemplateDirectiveModel and its subclasses probably
  shouldn't be public. (Also executeInternal probably should be
  protected.) Generally, we should avoid exposing things as published
  API-s, because they all become backward compatibility constraints.
  (It's major difficulty with libraries that thousands of projects
  depend on, as I have learned the hard way with FM2...)

- final MessageSourceResolvable messageResolvable = (messageResolvableModel != 
null)
  ? (MessageSourceResolvable) 
objectWrapperAndUnwrapper.unwrap(messageResolvableModel) : null;

  You can have ClassCastException here instead of a TemplateException
  that explains the higher level problem. Certainly you should
  introduce and then use something like:
  CallableUtil.getAndUnwrapArgument(..., MessageSourceResolvable.class, ...)

- Things similar to this:

<#assign expression="T(java.lang.Math).max(12.34, 56.78)" />
${spring.eval(expression)}

  or this:

<#assign pathInfo="http://freemarker.org/docs/index.html; />
Apache FreeMarker Manual

  I think they are more readable (for most of us anyway) without the
  intermediate variable that's use only once. Like:

${spring.eval("T(java.lang.Math).max(12.34, 
56.78)")}

> Thanks,
>
> Woonsan
>
>>
>> Cheers,
>>
>> Woonsan
>>
>>>
 (ref:
 https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl)

 Still need to add an example using 'message' named parameter.

 Regards,

 Woonsan

>
>> look at `spring.message("foo")`, I think you would intuitively think
>> that it prints the "foo" message. As of the others, I guess we don't
>> need "text" as you can write ${spring.message("foo")!'default'}, nor
>> do we need the xxxEscape parameters, as we have HTML auto-escaping and
>> `spring.message("foo")?jsString`.
>
> Oh, cool! I didn't know we have ?jsString. Perfect.
>
>>

 Something that would be interesting if the spring.message function can
 somehow tell if a message is plain text or HTML. Like you can
 configure which messages are HTML on name patterns (or a content
 pattern, like all HTML values start with ""). After all, without
 such a rule, how do the developers themselves know if a message should
 be HTML or plain text. Hopefully the have some exact policy for that.
 If spring.message knows that rule too, then for HTML messages it
 should return a TemplateMarkupOutputModel instead of a string, so it
 will be automatically non-escaped. Then people can just write
 ${spring.message("foo")} without worrying about `?noEsc`. And then we
 certainly don't need the directive "overload" either.
>>>
>>> As far as I know, MessageTag extends HtmlEscapingAwareTag which has
>>> the following javadoc:
>>>
>>>  * Provides a "htmlEscape" property for explicitly specifying 
>>> whether to
>>>  * apply HTML escaping. If not set, a page-level default (e.g. from the
>>>  * HtmlEscapeTag) or an application-wide default (the 
>>> "defaultHtmlEscape"
>>>  * context-param in {@code web.xml}) is used.
>>
>> So then it seems we indeed need some spring library configuration
>> parameter that associates an output format (as in
>> http://freemarker.org/docs/dgui_misc_autoescaping.html) to each
>> message, based on patterns. By default everything should be just plain
>> text, to be on the safe side (i.e., auto-escaping will happen for
>> them, because ${} does that). The equivalent of "defaultHtmlEscape"
>> being on is that you assoicate "HTML" output format to all messages.
>
> +1
>
>>
>> This also reinforces that, at least in the first iteration,
>> spring.message should be function only, not a directive.
>> `${spring.message("foo")}` isn't more verbose than
>> `<@spring.message "foo" />` anyway.
>
> +1
>
>>
>> BTW, I think it may worth having a special syntax for message
>> insertion in the template language. For example,
>> %{label.greet user, today} would be a syntactical sugar for
>> ${someframewok.message('label.greet', user, today)}. But that's
>> another topic.
>
> Sounds promising!
>
> Woonsan
>
>>
>>> Regards,
>>>
>>> Woonsan
>>>

>> By the 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Tue, Sep 5, 2017 at 8:58 AM, Woonsan Ko  wrote:
> On Sun, Sep 3, 2017 at 7:55 AM, Daniel Dekany  wrote:
>> Sunday, September 3, 2017, 6:29:54 AM, Woonsan Ko wrote:
>>
>>> On Sat, Sep 2, 2017 at 7:33 PM, Woonsan Ko  wrote:
 On Sat, Sep 2, 2017 at 3:36 AM, Daniel Dekany  wrote:
> Saturday, September 2, 2017, 5:24:11 AM, Woonsan Ko wrote:
>
>> On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany  
>> wrote:
>>> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:
>>>
 Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:

> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  
> wrote:
>> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  
>>> wrote:
 If you are going to implement these directly as
 TemplateDirectiveModel-s and TemplateFunctionModel-s, then you 
 better
 wait until I merge at least the FREEMARKER-63 PR... probably also
 FREEMARKER-64. I will try to do that tonight. At least 63.
>>>
>>> OK, I'll watch and wait for that. :-)
>>
>> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
>> for argument validation and other exception creation. See
>> AssertFailsDirective as an example. Of course, ideas for improving
>> CallableUtils are highly welcome.
>>
>> BTW, certainly there are several TemplateFunctionModel and
>> TemplateDirectiveModel implementations that could but don't yet use
>> CallableUtils for argument validation. If you spot some, you may go
>> ahead and improve them.
>
> Thank you so much! I've briefly browsed the PRs linked from the JIRA
> tickets, and it is really great!
>>>
>>> Though you better look at the examples in the 3.0 branch, because
>>> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
>>> I shouldn't do that.)
>>>
> Really easy to extend it with
> TemplateCallableModel. Very simple but really powerful! I also saw
> IncludePage directive (as named "include_page")  in
> freemarker-servlet; it looks really straightforward.
> I'll try to write equivalent directives or functions from spring JSP
> Tag Library [1] and spring-form JSP Tag Library [2].

 Certainly quite a few changes will be needed compared to the JSP
 taglib. One such question if when and how escaping related
 functionality will appear, as escaping is a core facility in FTL.
 Also there are strange things like ``.
 I'm not sure why that isn't a function (used like
 )...
>>>
>>> With correct JSP syntax that actually would be
>>>
>>>   
>>>
>>> if spring:url was a function. So it's kind of understandable that they
>>> rather go with
>>>
>>>   
>>>
>>> But in FreeMarker it would be just:
>>>
>>>   <#assign v = spring.url("somePath")>
>>>
>>> or if you want to print it into the HTML:
>>>
>>>   
>>>
>>> So this was a case where what's a custom tag in JSP should be a
>>> function in FreeMarker, not a directive.
>>>
 Also note that in FTL you can have positional parameters for
 directives, and named parameters for functions.
>>>
>>> Usually, if a directive has a required parameter, whose meaning is
>>> obvious for almost anybody, then that should be a positional
>>> parameter. A very clear case of this is <#if something>. A less clear
>>> case, but still maybe a good idea is making the "path" parameter of
>>> form:input, form:label etc. positional:
>>>
>>> 
>>>   <@form.label "contactPerson">Contact person
>>>   <@form.input "contactPerson"/>
>>> 
>>>
>>> I think anyone who knows even a little about Spring forms will know
>>> that "contactPerson" is the property name in the backing form bean. Or
>>> if not, path="contactPerson" is not much more helpful either.
>>>
>>> Another place where FreeMarker differs from the approach of the Spring
>>> JSP tags is when you refer to a value of the model (or to any Servlet
>>> attribute). Like, you have an "employee" bean in the Spring Model, and
>>> as far as I see in JSP you are supposed to bind that to a form like
>>> this:
>>>
>>>   
>>>
>>> While technically possible, that's quote alien from FreeMarker. If the
>>> directive wants to do something with the `emloyee` object, then pass
>>> the object itself to it as argument, not the name of it. Like this:
>>>
>>>   <@form.form action="/storeEmployee" model=employee>
>>>

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Sun, Sep 3, 2017 at 7:55 AM, Daniel Dekany  wrote:
> Sunday, September 3, 2017, 6:29:54 AM, Woonsan Ko wrote:
>
>> On Sat, Sep 2, 2017 at 7:33 PM, Woonsan Ko  wrote:
>>> On Sat, Sep 2, 2017 at 3:36 AM, Daniel Dekany  wrote:
 Saturday, September 2, 2017, 5:24:11 AM, Woonsan Ko wrote:

> On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany  wrote:
>> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:
>>
>>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>>
 On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  
 wrote:
> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>
>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  
>> wrote:
>>> If you are going to implement these directly as
>>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you 
>>> better
>>> wait until I merge at least the FREEMARKER-63 PR... probably also
>>> FREEMARKER-64. I will try to do that tonight. At least 63.
>>
>> OK, I'll watch and wait for that. :-)
>
> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
> for argument validation and other exception creation. See
> AssertFailsDirective as an example. Of course, ideas for improving
> CallableUtils are highly welcome.
>
> BTW, certainly there are several TemplateFunctionModel and
> TemplateDirectiveModel implementations that could but don't yet use
> CallableUtils for argument validation. If you spot some, you may go
> ahead and improve them.

 Thank you so much! I've briefly browsed the PRs linked from the JIRA
 tickets, and it is really great!
>>
>> Though you better look at the examples in the 3.0 branch, because
>> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
>> I shouldn't do that.)
>>
 Really easy to extend it with
 TemplateCallableModel. Very simple but really powerful! I also saw
 IncludePage directive (as named "include_page")  in
 freemarker-servlet; it looks really straightforward.
 I'll try to write equivalent directives or functions from spring JSP
 Tag Library [1] and spring-form JSP Tag Library [2].
>>>
>>> Certainly quite a few changes will be needed compared to the JSP
>>> taglib. One such question if when and how escaping related
>>> functionality will appear, as escaping is a core facility in FTL.
>>> Also there are strange things like ``.
>>> I'm not sure why that isn't a function (used like
>>> )...
>>
>> With correct JSP syntax that actually would be
>>
>>   
>>
>> if spring:url was a function. So it's kind of understandable that they
>> rather go with
>>
>>   
>>
>> But in FreeMarker it would be just:
>>
>>   <#assign v = spring.url("somePath")>
>>
>> or if you want to print it into the HTML:
>>
>>   
>>
>> So this was a case where what's a custom tag in JSP should be a
>> function in FreeMarker, not a directive.
>>
>>> Also note that in FTL you can have positional parameters for
>>> directives, and named parameters for functions.
>>
>> Usually, if a directive has a required parameter, whose meaning is
>> obvious for almost anybody, then that should be a positional
>> parameter. A very clear case of this is <#if something>. A less clear
>> case, but still maybe a good idea is making the "path" parameter of
>> form:input, form:label etc. positional:
>>
>> 
>>   <@form.label "contactPerson">Contact person
>>   <@form.input "contactPerson"/>
>> 
>>
>> I think anyone who knows even a little about Spring forms will know
>> that "contactPerson" is the property name in the backing form bean. Or
>> if not, path="contactPerson" is not much more helpful either.
>>
>> Another place where FreeMarker differs from the approach of the Spring
>> JSP tags is when you refer to a value of the model (or to any Servlet
>> attribute). Like, you have an "employee" bean in the Spring Model, and
>> as far as I see in JSP you are supposed to bind that to a form like
>> this:
>>
>>   
>>
>> While technically possible, that's quote alien from FreeMarker. If the
>> directive wants to do something with the `emloyee` object, then pass
>> the object itself to it as argument, not the name of it. Like this:
>>
>>   <@form.form action="/storeEmployee" model=employee>
>>
>> Unless, the `form` directive indeed has to know the *name* of the
>> variable, as opposed to just the value of it... I'm not sure if that's
>> the case here. But I have seen this 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Sunday, September 3, 2017, 6:29:54 AM, Woonsan Ko wrote:

> On Sat, Sep 2, 2017 at 7:33 PM, Woonsan Ko  wrote:
>> On Sat, Sep 2, 2017 at 3:36 AM, Daniel Dekany  wrote:
>>> Saturday, September 2, 2017, 5:24:11 AM, Woonsan Ko wrote:
>>>
 On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany  wrote:
> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:
>
>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  
>>> wrote:
 Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  
> wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

 FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
 for argument validation and other exception creation. See
 AssertFailsDirective as an example. Of course, ideas for improving
 CallableUtils are highly welcome.

 BTW, certainly there are several TemplateFunctionModel and
 TemplateDirectiveModel implementations that could but don't yet use
 CallableUtils for argument validation. If you spot some, you may go
 ahead and improve them.
>>>
>>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>>> tickets, and it is really great!
>
> Though you better look at the examples in the 3.0 branch, because
> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
> I shouldn't do that.)
>
>>> Really easy to extend it with
>>> TemplateCallableModel. Very simple but really powerful! I also saw
>>> IncludePage directive (as named "include_page")  in
>>> freemarker-servlet; it looks really straightforward.
>>> I'll try to write equivalent directives or functions from spring JSP
>>> Tag Library [1] and spring-form JSP Tag Library [2].
>>
>> Certainly quite a few changes will be needed compared to the JSP
>> taglib. One such question if when and how escaping related
>> functionality will appear, as escaping is a core facility in FTL.
>> Also there are strange things like ``.
>> I'm not sure why that isn't a function (used like
>> )...
>
> With correct JSP syntax that actually would be
>
>   
>
> if spring:url was a function. So it's kind of understandable that they
> rather go with
>
>   
>
> But in FreeMarker it would be just:
>
>   <#assign v = spring.url("somePath")>
>
> or if you want to print it into the HTML:
>
>   
>
> So this was a case where what's a custom tag in JSP should be a
> function in FreeMarker, not a directive.
>
>> Also note that in FTL you can have positional parameters for
>> directives, and named parameters for functions.
>
> Usually, if a directive has a required parameter, whose meaning is
> obvious for almost anybody, then that should be a positional
> parameter. A very clear case of this is <#if something>. A less clear
> case, but still maybe a good idea is making the "path" parameter of
> form:input, form:label etc. positional:
>
> 
>   <@form.label "contactPerson">Contact person
>   <@form.input "contactPerson"/>
> 
>
> I think anyone who knows even a little about Spring forms will know
> that "contactPerson" is the property name in the backing form bean. Or
> if not, path="contactPerson" is not much more helpful either.
>
> Another place where FreeMarker differs from the approach of the Spring
> JSP tags is when you refer to a value of the model (or to any Servlet
> attribute). Like, you have an "employee" bean in the Spring Model, and
> as far as I see in JSP you are supposed to bind that to a form like
> this:
>
>   
>
> While technically possible, that's quote alien from FreeMarker. If the
> directive wants to do something with the `emloyee` object, then pass
> the object itself to it as argument, not the name of it. Like this:
>
>   <@form.form action="/storeEmployee" model=employee>
>
> Unless, the `form` directive indeed has to know the *name* of the
> variable, as opposed to just the value of it... I'm not sure if that's
> the case here. But I have seen this patter a few times in JSP (pass
> the name of something instead of the thing itself), and had the
> feeling that often it's just to avoid the more noisy
> `model="${employee}"` syntax. 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Sat, Sep 2, 2017 at 3:11 AM, Daniel Dekany  wrote:
> Saturday, September 2, 2017, 5:03:51 AM, Woonsan Ko wrote:
>
>> On Thu, Aug 24, 2017 at 3:53 AM, Daniel Dekany  wrote:
>>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>>
 On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>
>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  
>> wrote:
>>> If you are going to implement these directly as
>>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>>> wait until I merge at least the FREEMARKER-63 PR... probably also
>>> FREEMARKER-64. I will try to do that tonight. At least 63.
>>
>> OK, I'll watch and wait for that. :-)
>
> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
> for argument validation and other exception creation. See
> AssertFailsDirective as an example. Of course, ideas for improving
> CallableUtils are highly welcome.
>
> BTW, certainly there are several TemplateFunctionModel and
> TemplateDirectiveModel implementations that could but don't yet use
> CallableUtils for argument validation. If you spot some, you may go
> ahead and improve them.

 Thank you so much! I've briefly browsed the PRs linked from the JIRA
 tickets, and it is really great! Really easy to extend it with
 TemplateCallableModel. Very simple but really powerful! I also saw
 IncludePage directive (as named "include_page")  in
 freemarker-servlet; it looks really straightforward.
 I'll try to write equivalent directives or functions from spring JSP
 Tag Library [1] and spring-form JSP Tag Library [2].
>>>
>>> Certainly quite a few changes will be needed compared to the JSP
>>> taglib. One such question if when and how escaping related
>>> functionality will appear, as escaping is a core facility in FTL.
>>> Also there are strange things like ``.
>>> I'm not sure why that isn't a function (used like
>>> )...
>>
>> According to spring.tld, it's supposed to substitute the JSTL  />> tag. And it has many optional parameters: context, var, scope,
>> htmlEscape, javaScriptEscape. It was impossible to define a convenient
>> JSTL function instead. So, it makes sense in their perspective as JSP
>> taglibs.
>> Another thing is it can save the generated URL string into a variable
>> by setting 'var', so that you don't need to invoke the function
>> multiple times for the same URL.
>
> They could just assign the return value of spring:url() to a variable
> for that. Though  is
> quite verbose for sure, but that's how the JSP syntax elsewhere too.
> <#assign v = spring.url("foo")> is significantly less verbose.

Yeah, that could work. Function seems the right choice in FreeMarker then.

>
>> I personally think it gives convenience to developers if we provide
>> both a directive and function for the URL tag in FreeMarker. Since
>> FreeMarker supports optional position/named parameters, each option
>> would be easier to do.
>
> When is it more practical to call spring.url as directive than as a
> function?

I just thought it could be an easier mapping from tag to directive
when they need to convert existing code.
But in the second thought, function seems okay.

>
>>> Also note that in FTL you can have positional parameters for
>>> directives, and named parameters for functions. Also that a value can
>>> be both a function and a directive; maybe useful for message printing.
>>> If called like a function, it returns a string, if called like a tag,
>>> it prints the message without escaping... maybe.
>>>
 By the way, I'm wondering what the best practices are in naming those
 models. Should it be better with 'form', 'spring_form', 'spring.form',
 or something else? Prefixing with something sounds safer to me.
>>>
>>> In the templates they should be accessible as <@spring.bind ...> and
>>> such. In the case of the form tags, as it's in a separate namespace in
>>> JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100%
>>> sure if its practical the structure of the JSP taglibs so closely, and
>>> maybe we could just go with <@spring.input ...>. I don't know.)
>>
>> I personally prefer keeping a similar structure of the JSP taglibs as
>> possible, which could make developers easier to migrate.
>> So, <@spring.bind ...> and <@form.input ...> sound good to me.
>
> Sound got to me too.
>
>> Perhaps we can make the namespaces configurable through view
>> configurations.
>
> Though for now it's not needed.

OK.

Regards,

Woonsan

>
>> Regards,
>>
>> Woonsan
>>
>>>
 Regards,

 Woonsan

 [1]
 https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
 [2]
 https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html

>

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Saturday, September 2, 2017, 5:24:11 AM, Woonsan Ko wrote:

> On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany  wrote:
>> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:
>>
>>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>>
 On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>
>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  
>> wrote:
>>> If you are going to implement these directly as
>>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>>> wait until I merge at least the FREEMARKER-63 PR... probably also
>>> FREEMARKER-64. I will try to do that tonight. At least 63.
>>
>> OK, I'll watch and wait for that. :-)
>
> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
> for argument validation and other exception creation. See
> AssertFailsDirective as an example. Of course, ideas for improving
> CallableUtils are highly welcome.
>
> BTW, certainly there are several TemplateFunctionModel and
> TemplateDirectiveModel implementations that could but don't yet use
> CallableUtils for argument validation. If you spot some, you may go
> ahead and improve them.

 Thank you so much! I've briefly browsed the PRs linked from the JIRA
 tickets, and it is really great!
>>
>> Though you better look at the examples in the 3.0 branch, because
>> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
>> I shouldn't do that.)
>>
 Really easy to extend it with
 TemplateCallableModel. Very simple but really powerful! I also saw
 IncludePage directive (as named "include_page")  in
 freemarker-servlet; it looks really straightforward.
 I'll try to write equivalent directives or functions from spring JSP
 Tag Library [1] and spring-form JSP Tag Library [2].
>>>
>>> Certainly quite a few changes will be needed compared to the JSP
>>> taglib. One such question if when and how escaping related
>>> functionality will appear, as escaping is a core facility in FTL.
>>> Also there are strange things like ``.
>>> I'm not sure why that isn't a function (used like
>>> )...
>>
>> With correct JSP syntax that actually would be
>>
>>   
>>
>> if spring:url was a function. So it's kind of understandable that they
>> rather go with
>>
>>   
>>
>> But in FreeMarker it would be just:
>>
>>   <#assign v = spring.url("somePath")>
>>
>> or if you want to print it into the HTML:
>>
>>   
>>
>> So this was a case where what's a custom tag in JSP should be a
>> function in FreeMarker, not a directive.
>>
>>> Also note that in FTL you can have positional parameters for
>>> directives, and named parameters for functions.
>>
>> Usually, if a directive has a required parameter, whose meaning is
>> obvious for almost anybody, then that should be a positional
>> parameter. A very clear case of this is <#if something>. A less clear
>> case, but still maybe a good idea is making the "path" parameter of
>> form:input, form:label etc. positional:
>>
>> 
>>   <@form.label "contactPerson">Contact person
>>   <@form.input "contactPerson"/>
>> 
>>
>> I think anyone who knows even a little about Spring forms will know
>> that "contactPerson" is the property name in the backing form bean. Or
>> if not, path="contactPerson" is not much more helpful either.
>>
>> Another place where FreeMarker differs from the approach of the Spring
>> JSP tags is when you refer to a value of the model (or to any Servlet
>> attribute). Like, you have an "employee" bean in the Spring Model, and
>> as far as I see in JSP you are supposed to bind that to a form like
>> this:
>>
>>   
>>
>> While technically possible, that's quote alien from FreeMarker. If the
>> directive wants to do something with the `emloyee` object, then pass
>> the object itself to it as argument, not the name of it. Like this:
>>
>>   <@form.form action="/storeEmployee" model=employee>
>>
>> Unless, the `form` directive indeed has to know the *name* of the
>> variable, as opposed to just the value of it... I'm not sure if that's
>> the case here. But I have seen this patter a few times in JSP (pass
>> the name of something instead of the thing itself), and had the
>> feeling that often it's just to avoid the more noisy
>> `model="${employee}"` syntax. FreeMarker has no such problem, as it's
>> just `model=employee` there, which is even less verbose than passing
>> the name of the variable.
>>
>>> Also that a value can be both a function and a directive; maybe
>>> useful for message printing. If called like a function, it returns a
>>> string, if called like a tag, it prints the message without
>>> escaping... maybe.
>>
>> So that practically means that these two will be equivalent:
>>
>>   <@spring.message "foo" />
>>
>>   ${spring.message("foo")?noEsc}
>>
>> Now this is maybe too 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Saturday, September 2, 2017, 5:03:51 AM, Woonsan Ko wrote:

> On Thu, Aug 24, 2017 at 3:53 AM, Daniel Dekany  wrote:
>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
 Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

 FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
 for argument validation and other exception creation. See
 AssertFailsDirective as an example. Of course, ideas for improving
 CallableUtils are highly welcome.

 BTW, certainly there are several TemplateFunctionModel and
 TemplateDirectiveModel implementations that could but don't yet use
 CallableUtils for argument validation. If you spot some, you may go
 ahead and improve them.
>>>
>>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>>> tickets, and it is really great! Really easy to extend it with
>>> TemplateCallableModel. Very simple but really powerful! I also saw
>>> IncludePage directive (as named "include_page")  in
>>> freemarker-servlet; it looks really straightforward.
>>> I'll try to write equivalent directives or functions from spring JSP
>>> Tag Library [1] and spring-form JSP Tag Library [2].
>>
>> Certainly quite a few changes will be needed compared to the JSP
>> taglib. One such question if when and how escaping related
>> functionality will appear, as escaping is a core facility in FTL.
>> Also there are strange things like ``.
>> I'm not sure why that isn't a function (used like
>> )...
>
> According to spring.tld, it's supposed to substitute the JSTL > tag. And it has many optional parameters: context, var, scope,
> htmlEscape, javaScriptEscape. It was impossible to define a convenient
> JSTL function instead. So, it makes sense in their perspective as JSP
> taglibs.
> Another thing is it can save the generated URL string into a variable
> by setting 'var', so that you don't need to invoke the function
> multiple times for the same URL.

They could just assign the return value of spring:url() to a variable
for that. Though  is
quite verbose for sure, but that's how the JSP syntax elsewhere too.
<#assign v = spring.url("foo")> is significantly less verbose.

> I personally think it gives convenience to developers if we provide
> both a directive and function for the URL tag in FreeMarker. Since
> FreeMarker supports optional position/named parameters, each option
> would be easier to do.

When is it more practical to call spring.url as directive than as a
function?

>> Also note that in FTL you can have positional parameters for
>> directives, and named parameters for functions. Also that a value can
>> be both a function and a directive; maybe useful for message printing.
>> If called like a function, it returns a string, if called like a tag,
>> it prints the message without escaping... maybe.
>>
>>> By the way, I'm wondering what the best practices are in naming those
>>> models. Should it be better with 'form', 'spring_form', 'spring.form',
>>> or something else? Prefixing with something sounds safer to me.
>>
>> In the templates they should be accessible as <@spring.bind ...> and
>> such. In the case of the form tags, as it's in a separate namespace in
>> JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100%
>> sure if its practical the structure of the JSP taglibs so closely, and
>> maybe we could just go with <@spring.input ...>. I don't know.)
>
> I personally prefer keeping a similar structure of the JSP taglibs as
> possible, which could make developers easier to migrate.
> So, <@spring.bind ...> and <@form.input ...> sound good to me.

Sound got to me too.

> Perhaps we can make the namespaces configurable through view
> configurations.

Though for now it's not needed.

> Regards,
>
> Woonsan
>
>>
>>> Regards,
>>>
>>> Woonsan
>>>
>>> [1]
>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
>>> [2]
>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>>

>> Besides, just to be absolutely clear, I would merge your current PR as
>> well, if it doesn't raise licensing issues, which is of course a
>> blocker.
>
> Sure, no worries. I was also under a concern about that and wanted to
> get feedbacks before doing too much. ;-)
>
> Regards,
>
> Woonsan
>
>>
>>
>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>
>>> On Sun, Aug 6, 2017 at 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany  wrote:
> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:
>
>> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
 Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

 FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
 for argument validation and other exception creation. See
 AssertFailsDirective as an example. Of course, ideas for improving
 CallableUtils are highly welcome.

 BTW, certainly there are several TemplateFunctionModel and
 TemplateDirectiveModel implementations that could but don't yet use
 CallableUtils for argument validation. If you spot some, you may go
 ahead and improve them.
>>>
>>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>>> tickets, and it is really great!
>
> Though you better look at the examples in the 3.0 branch, because
> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
> I shouldn't do that.)
>
>>> Really easy to extend it with
>>> TemplateCallableModel. Very simple but really powerful! I also saw
>>> IncludePage directive (as named "include_page")  in
>>> freemarker-servlet; it looks really straightforward.
>>> I'll try to write equivalent directives or functions from spring JSP
>>> Tag Library [1] and spring-form JSP Tag Library [2].
>>
>> Certainly quite a few changes will be needed compared to the JSP
>> taglib. One such question if when and how escaping related
>> functionality will appear, as escaping is a core facility in FTL.
>> Also there are strange things like ``.
>> I'm not sure why that isn't a function (used like
>> )...
>
> With correct JSP syntax that actually would be
>
>   
>
> if spring:url was a function. So it's kind of understandable that they
> rather go with
>
>   
>
> But in FreeMarker it would be just:
>
>   <#assign v = spring.url("somePath")>
>
> or if you want to print it into the HTML:
>
>   
>
> So this was a case where what's a custom tag in JSP should be a
> function in FreeMarker, not a directive.
>
>> Also note that in FTL you can have positional parameters for
>> directives, and named parameters for functions.
>
> Usually, if a directive has a required parameter, whose meaning is
> obvious for almost anybody, then that should be a positional
> parameter. A very clear case of this is <#if something>. A less clear
> case, but still maybe a good idea is making the "path" parameter of
> form:input, form:label etc. positional:
>
> 
>   <@form.label "contactPerson">Contact person
>   <@form.input "contactPerson"/>
> 
>
> I think anyone who knows even a little about Spring forms will know
> that "contactPerson" is the property name in the backing form bean. Or
> if not, path="contactPerson" is not much more helpful either.
>
> Another place where FreeMarker differs from the approach of the Spring
> JSP tags is when you refer to a value of the model (or to any Servlet
> attribute). Like, you have an "employee" bean in the Spring Model, and
> as far as I see in JSP you are supposed to bind that to a form like
> this:
>
>   
>
> While technically possible, that's quote alien from FreeMarker. If the
> directive wants to do something with the `emloyee` object, then pass
> the object itself to it as argument, not the name of it. Like this:
>
>   <@form.form action="/storeEmployee" model=employee>
>
> Unless, the `form` directive indeed has to know the *name* of the
> variable, as opposed to just the value of it... I'm not sure if that's
> the case here. But I have seen this patter a few times in JSP (pass
> the name of something instead of the thing itself), and had the
> feeling that often it's just to avoid the more noisy
> `model="${employee}"` syntax. FreeMarker has no such problem, as it's
> just `model=employee` there, which is even less verbose than passing
> the name of the variable.
>
>> Also that a value can be both a function and a directive; maybe
>> useful for message printing. If called like a function, it returns a
>> string, if called like a tag, it prints the message without
>> escaping... maybe.
>
> So that practically means that these two will be equivalent:
>
>   <@spring.message "foo" />
>
>   ${spring.message("foo")?noEsc}
>
> Now this is maybe too confusing for most users and thus is a bad idea.
> But if spring.message will only have one type, then that's surely
> function, not directive (unlike in the FM2 Spring integration).

 tag 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Thu, Aug 24, 2017 at 3:53 AM, Daniel Dekany  wrote:
> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>
>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
>>> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>>>
 On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
> If you are going to implement these directly as
> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
> wait until I merge at least the FREEMARKER-63 PR... probably also
> FREEMARKER-64. I will try to do that tonight. At least 63.

 OK, I'll watch and wait for that. :-)
>>>
>>> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
>>> for argument validation and other exception creation. See
>>> AssertFailsDirective as an example. Of course, ideas for improving
>>> CallableUtils are highly welcome.
>>>
>>> BTW, certainly there are several TemplateFunctionModel and
>>> TemplateDirectiveModel implementations that could but don't yet use
>>> CallableUtils for argument validation. If you spot some, you may go
>>> ahead and improve them.
>>
>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>> tickets, and it is really great! Really easy to extend it with
>> TemplateCallableModel. Very simple but really powerful! I also saw
>> IncludePage directive (as named "include_page")  in
>> freemarker-servlet; it looks really straightforward.
>> I'll try to write equivalent directives or functions from spring JSP
>> Tag Library [1] and spring-form JSP Tag Library [2].
>
> Certainly quite a few changes will be needed compared to the JSP
> taglib. One such question if when and how escaping related
> functionality will appear, as escaping is a core facility in FTL.
> Also there are strange things like ``.
> I'm not sure why that isn't a function (used like
> )...

According to spring.tld, it's supposed to substitute the JSTL  tag. And it has many optional parameters: context, var, scope,
htmlEscape, javaScriptEscape. It was impossible to define a convenient
JSTL function instead. So, it makes sense in their perspective as JSP
taglibs.
Another thing is it can save the generated URL string into a variable
by setting 'var', so that you don't need to invoke the function
multiple times for the same URL.
I personally think it gives convenience to developers if we provide
both a directive and function for the URL tag in FreeMarker. Since
FreeMarker supports optional position/named parameters, each option
would be easier to do.

>
> Also note that in FTL you can have positional parameters for
> directives, and named parameters for functions. Also that a value can
> be both a function and a directive; maybe useful for message printing.
> If called like a function, it returns a string, if called like a tag,
> it prints the message without escaping... maybe.
>
>> By the way, I'm wondering what the best practices are in naming those
>> models. Should it be better with 'form', 'spring_form', 'spring.form',
>> or something else? Prefixing with something sounds safer to me.
>
> In the templates they should be accessible as <@spring.bind ...> and
> such. In the case of the form tags, as it's in a separate namespace in
> JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100%
> sure if its practical the structure of the JSP taglibs so closely, and
> maybe we could just go with <@spring.input ...>. I don't know.)

I personally prefer keeping a similar structure of the JSP taglibs as
possible, which could make developers easier to migrate.
So, <@spring.bind ...> and <@form.input ...> sound good to me. Perhaps
we can make the namespaces configurable through view configurations.

Regards,

Woonsan

>
>> Regards,
>>
>> Woonsan
>>
>> [1]
>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
>> [2]
>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>
>>>
> Besides, just to be absolutely clear, I would merge your current PR as
> well, if it doesn't raise licensing issues, which is of course a
> blocker.

 Sure, no worries. I was also under a concern about that and wanted to
 get feedbacks before doing too much. ;-)

 Regards,

 Woonsan

>
>
> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>
>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  
>> wrote:
>>> The big problem is that spring.ftl is copyrighted by some of the
>>> Spring authors (or the Spring project as a whole - it's not clear). So
>>> certainly we can't just copy it. It has to be reimplemented without
>>> looking at the source, or something absurd like that. Perhaps the best
>>> is to start out from the spring JSP taglib, as that's the most widely
>>> used templating solution (I assume), so certainly that's the one where
>>> all the 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Tuesday, August 29, 2017, 8:48:34 PM, Woonsan Ko wrote:

> On Tue, Aug 29, 2017 at 10:40 AM, Daniel Dekany  wrote:
>> Tuesday, August 29, 2017, 3:03:02 PM, Woonsan Ko wrote:
>>
>>> On Tue, Aug 29, 2017 at 5:00 AM, Daniel Dekany  wrote:
 Tuesday, August 29, 2017, 5:25:31 AM, Woonsan Ko wrote:

> Hi Daniel,
>
> Thanks for the remarks and hints! Please see my question inline.
>
> On Sat, Aug 26, 2017 at 4:50 AM, Daniel Dekany  
> wrote:
>> Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:
>>
>> [snip]
>>>   <#macro foo>
>>> <#local status = 'blah'>
>>> <@spring.bind "user.name">
>>>   ${status.value} <#-- Means 'blah'.value, won't work -->
>>
>> To clarify, here I have assumed that spring.bind calls
>> env.setVariable("status", ...) internally. Then the local with the
>> same name shadows that tempolate-namespace scoped variable.
>
> It seems working with env.setVariable("status", ...):
>
> // Excerpt from
> https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/BindDirective.java

 Looks good. But what are your thoughts on using a nested content
 parameter instead?
>>>
>>> I'm sure I'm missing something or in misunderstandings. I want to try
>>> the option using a nested content parameter instead, but I don't know
>>> how to do that. ;-)
>>> Ideally, <@spring.bind ... /> directive needs to set a local variable
>>> called "status" or whatever (if the variable name can be given by a
>>> nested content parameter) and developers should be able to use the
>>> status variable ("status" or whatever) somehow inside the directive.
>>> So, my assumption was, if the parameter is given to the directive, I
>>> can probably fill in a variable somehow by resolving the bind status
>>> object. I guess I'm totally ignorant on how nested content parameters
>>> work with directives...
>>
>> A directive can't create a nested content variable. The caller can
>> declare a nested content parameter, like `<@spring.bind ...; status>`,
>> and then the directive can specify the actual value of that parameter
>> when it calls the nested content with
>> `callPlace.executeNestedContent`. (Of course it's likely that the
>> caller will chose a shorter name, like `s`; see earlier mails.)
>
> Ah, I think I now understand it!
> So, for example, if I do this:
>
>   callPlace.executeNestedContent(new TemplateModel [] { status }, out, env);
>
> , then the nested template may read/use the passed status object by
> referring to by the name (e.g, 's') given by themselves, right?

Right.

> I totally overlooked the fact that I can pass arguments to the nested
> content when invoking #executeNestedContent().
> I'll try it out again. I personally it is better to use nested content
> parameters instead of #setVariable() as they are local.
> The following example seems a lot better than the JSP taglib to me:
>
> <@spring.bind "user.email"; status>
>   
>  Thanks again for the advice!
>
> Cheers,
>
> Woonsan
>
>>
>> You may wonder if we should allow the directive to create a nested
>> content variable. I think it's a probably a quite bad library design
>> if you need that. Creating variables without the caller seeing that
>> makes understanding what's going on significantly harder. Worse, that
>> magically appearing variable can hide a variable from a higher scope.
>> If the caller doesn't ask for the creation of the variable, then that
>> variable should be under the `spring` namespace. Of course that
>> (`spring.status`) would be more verbose than using a nested content
>> parameter, so it doesn't make sense in this case.
>>
>>> Regards,
>>>
>>> Woonsan
>>>

> Another question: is it okay to assume that I have a
> DefaultObjectWrapper when this directive is executed and throw an
> exception otherwise?

 At the moment it's enough to expect it to be an
 ObjectWrapperAndUnwrapper. FreeMarkerServlet also requires that BTW.
 I'm not sure if in the future expecting DefaultObjectWrapper will be
 necessary, but hopefully not. (Custom JSP tag support expects a
 DefaultObjectWrapper at the moment, for wrapping JSP functions.)

>> [snip]
>>> With nested content parameter it's also more obvious what's going on,
>>> and if you chose a shorter name it's not that verbose either:
>>>
>>>   <@spring.bind "user.name"; s>
>>> ${s.value}
>
> If I choose to use nested content parameter instead of having
> env.setVariable() calls, how can I get access to the parameter, s?
> Can I access it through any argument of the #execute() method in the
> Java code? Any example java code using nested content parameter?

 I'm not sure what you try to achieve. As the nested content parameter
 is local to 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Tue, Aug 29, 2017 at 2:48 PM, Woonsan Ko  wrote:
> On Tue, Aug 29, 2017 at 10:40 AM, Daniel Dekany  wrote:
>> Tuesday, August 29, 2017, 3:03:02 PM, Woonsan Ko wrote:
>>
>>> On Tue, Aug 29, 2017 at 5:00 AM, Daniel Dekany  wrote:
 Tuesday, August 29, 2017, 5:25:31 AM, Woonsan Ko wrote:

> Hi Daniel,
>
> Thanks for the remarks and hints! Please see my question inline.
>
> On Sat, Aug 26, 2017 at 4:50 AM, Daniel Dekany  
> wrote:
>> Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:
>>
>> [snip]
>>>   <#macro foo>
>>> <#local status = 'blah'>
>>> <@spring.bind "user.name">
>>>   ${status.value} <#-- Means 'blah'.value, won't work -->
>>
>> To clarify, here I have assumed that spring.bind calls
>> env.setVariable("status", ...) internally. Then the local with the
>> same name shadows that tempolate-namespace scoped variable.
>
> It seems working with env.setVariable("status", ...):
>
> // Excerpt from
> https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/BindDirective.java

 Looks good. But what are your thoughts on using a nested content
 parameter instead?
>>>
>>> I'm sure I'm missing something or in misunderstandings. I want to try
>>> the option using a nested content parameter instead, but I don't know
>>> how to do that. ;-)
>>> Ideally, <@spring.bind ... /> directive needs to set a local variable
>>> called "status" or whatever (if the variable name can be given by a
>>> nested content parameter) and developers should be able to use the
>>> status variable ("status" or whatever) somehow inside the directive.
>>> So, my assumption was, if the parameter is given to the directive, I
>>> can probably fill in a variable somehow by resolving the bind status
>>> object. I guess I'm totally ignorant on how nested content parameters
>>> work with directives...
>>
>> A directive can't create a nested content variable. The caller can
>> declare a nested content parameter, like `<@spring.bind ...; status>`,
>> and then the directive can specify the actual value of that parameter
>> when it calls the nested content with
>> `callPlace.executeNestedContent`. (Of course it's likely that the
>> caller will chose a shorter name, like `s`; see earlier mails.)
>
> Ah, I think I now understand it!
> So, for example, if I do this:
>
>   callPlace.executeNestedContent(new TemplateModel [] { status }, out, env);
>
> , then the nested template may read/use the passed status object by
> referring to by the name (e.g, 's') given by themselves, right?
>
> I totally overlooked the fact that I can pass arguments to the nested
> content when invoking #executeNestedContent().
> I'll try it out again. I personally it is better to use nested content
> parameters instead of #setVariable() as they are local.
> The following example seems a lot better than the JSP taglib to me:
>
> <@spring.bind "user.email"; status>
>   
> https://github.com/woonsan/incubator-freemarker/commit/b656f1e1f7c1b0875526f2224db1fc793e1172d2
- 
https://github.com/woonsan/spring-mvc-freemarker3-demo/commit/e2530f62e1d8b1266f9b426dd3779bc26b1283bd
  (I'll move this temporary demo project to unit tests later when making PRs.)

Regards,

Woonsan

>
> Thanks again for the advice!
>
> Cheers,
>
> Woonsan
>
>>
>> You may wonder if we should allow the directive to create a nested
>> content variable. I think it's a probably a quite bad library design
>> if you need that. Creating variables without the caller seeing that
>> makes understanding what's going on significantly harder. Worse, that
>> magically appearing variable can hide a variable from a higher scope.
>> If the caller doesn't ask for the creation of the variable, then that
>> variable should be under the `spring` namespace. Of course that
>> (`spring.status`) would be more verbose than using a nested content
>> parameter, so it doesn't make sense in this case.
>>
>>> Regards,
>>>
>>> Woonsan
>>>

> Another question: is it okay to assume that I have a
> DefaultObjectWrapper when this directive is executed and throw an
> exception otherwise?

 At the moment it's enough to expect it to be an
 ObjectWrapperAndUnwrapper. FreeMarkerServlet also requires that BTW.
 I'm not sure if in the future expecting DefaultObjectWrapper will be
 necessary, but hopefully not. (Custom JSP tag support expects a
 DefaultObjectWrapper at the moment, for wrapping JSP functions.)

>> [snip]
>>> With nested content parameter it's also more obvious what's going on,
>>> and if you chose a shorter name it's not that verbose either:
>>>
>>>   <@spring.bind "user.name"; s>
>>> ${s.value}
>
> If I choose to use nested content parameter instead of having
> 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Tue, Aug 29, 2017 at 10:40 AM, Daniel Dekany  wrote:
> Tuesday, August 29, 2017, 3:03:02 PM, Woonsan Ko wrote:
>
>> On Tue, Aug 29, 2017 at 5:00 AM, Daniel Dekany  wrote:
>>> Tuesday, August 29, 2017, 5:25:31 AM, Woonsan Ko wrote:
>>>
 Hi Daniel,

 Thanks for the remarks and hints! Please see my question inline.

 On Sat, Aug 26, 2017 at 4:50 AM, Daniel Dekany  wrote:
> Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:
>
> [snip]
>>   <#macro foo>
>> <#local status = 'blah'>
>> <@spring.bind "user.name">
>>   ${status.value} <#-- Means 'blah'.value, won't work -->
>
> To clarify, here I have assumed that spring.bind calls
> env.setVariable("status", ...) internally. Then the local with the
> same name shadows that tempolate-namespace scoped variable.

 It seems working with env.setVariable("status", ...):

 // Excerpt from
 https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/BindDirective.java
>>>
>>> Looks good. But what are your thoughts on using a nested content
>>> parameter instead?
>>
>> I'm sure I'm missing something or in misunderstandings. I want to try
>> the option using a nested content parameter instead, but I don't know
>> how to do that. ;-)
>> Ideally, <@spring.bind ... /> directive needs to set a local variable
>> called "status" or whatever (if the variable name can be given by a
>> nested content parameter) and developers should be able to use the
>> status variable ("status" or whatever) somehow inside the directive.
>> So, my assumption was, if the parameter is given to the directive, I
>> can probably fill in a variable somehow by resolving the bind status
>> object. I guess I'm totally ignorant on how nested content parameters
>> work with directives...
>
> A directive can't create a nested content variable. The caller can
> declare a nested content parameter, like `<@spring.bind ...; status>`,
> and then the directive can specify the actual value of that parameter
> when it calls the nested content with
> `callPlace.executeNestedContent`. (Of course it's likely that the
> caller will chose a shorter name, like `s`; see earlier mails.)

Ah, I think I now understand it!
So, for example, if I do this:

  callPlace.executeNestedContent(new TemplateModel [] { status }, out, env);

, then the nested template may read/use the passed status object by
referring to by the name (e.g, 's') given by themselves, right?

I totally overlooked the fact that I can pass arguments to the nested
content when invoking #executeNestedContent().
I'll try it out again. I personally it is better to use nested content
parameters instead of #setVariable() as they are local.
The following example seems a lot better than the JSP taglib to me:

<@spring.bind "user.email"; status>
  

> You may wonder if we should allow the directive to create a nested
> content variable. I think it's a probably a quite bad library design
> if you need that. Creating variables without the caller seeing that
> makes understanding what's going on significantly harder. Worse, that
> magically appearing variable can hide a variable from a higher scope.
> If the caller doesn't ask for the creation of the variable, then that
> variable should be under the `spring` namespace. Of course that
> (`spring.status`) would be more verbose than using a nested content
> parameter, so it doesn't make sense in this case.
>
>> Regards,
>>
>> Woonsan
>>
>>>
 Another question: is it okay to assume that I have a
 DefaultObjectWrapper when this directive is executed and throw an
 exception otherwise?
>>>
>>> At the moment it's enough to expect it to be an
>>> ObjectWrapperAndUnwrapper. FreeMarkerServlet also requires that BTW.
>>> I'm not sure if in the future expecting DefaultObjectWrapper will be
>>> necessary, but hopefully not. (Custom JSP tag support expects a
>>> DefaultObjectWrapper at the moment, for wrapping JSP functions.)
>>>
> [snip]
>> With nested content parameter it's also more obvious what's going on,
>> and if you chose a shorter name it's not that verbose either:
>>
>>   <@spring.bind "user.name"; s>
>> ${s.value}

 If I choose to use nested content parameter instead of having
 env.setVariable() calls, how can I get access to the parameter, s?
 Can I access it through any argument of the #execute() method in the
 Java code? Any example java code using nested content parameter?
>>>
>>> I'm not sure what you try to achieve. As the nested content parameter
>>> is local to the nested content, similarly as a local variable is local
>>> to the method body in Java, where do you want to access `s` from, and
>>> why?
>>>
 Thanks in advance,

 Woonsan

> [snip]
>
> Eh... of course the comment is 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Tuesday, August 29, 2017, 3:03:02 PM, Woonsan Ko wrote:

> On Tue, Aug 29, 2017 at 5:00 AM, Daniel Dekany  wrote:
>> Tuesday, August 29, 2017, 5:25:31 AM, Woonsan Ko wrote:
>>
>>> Hi Daniel,
>>>
>>> Thanks for the remarks and hints! Please see my question inline.
>>>
>>> On Sat, Aug 26, 2017 at 4:50 AM, Daniel Dekany  wrote:
 Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:

 [snip]
>   <#macro foo>
> <#local status = 'blah'>
> <@spring.bind "user.name">
>   ${status.value} <#-- Means 'blah'.value, won't work -->

 To clarify, here I have assumed that spring.bind calls
 env.setVariable("status", ...) internally. Then the local with the
 same name shadows that tempolate-namespace scoped variable.
>>>
>>> It seems working with env.setVariable("status", ...):
>>>
>>> // Excerpt from
>>> https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/BindDirective.java
>>
>> Looks good. But what are your thoughts on using a nested content
>> parameter instead?
>
> I'm sure I'm missing something or in misunderstandings. I want to try
> the option using a nested content parameter instead, but I don't know
> how to do that. ;-)
> Ideally, <@spring.bind ... /> directive needs to set a local variable
> called "status" or whatever (if the variable name can be given by a
> nested content parameter) and developers should be able to use the
> status variable ("status" or whatever) somehow inside the directive.
> So, my assumption was, if the parameter is given to the directive, I
> can probably fill in a variable somehow by resolving the bind status
> object. I guess I'm totally ignorant on how nested content parameters
> work with directives...

A directive can't create a nested content variable. The caller can
declare a nested content parameter, like `<@spring.bind ...; status>`,
and then the directive can specify the actual value of that parameter
when it calls the nested content with
`callPlace.executeNestedContent`. (Of course it's likely that the
caller will chose a shorter name, like `s`; see earlier mails.)

You may wonder if we should allow the directive to create a nested
content variable. I think it's a probably a quite bad library design
if you need that. Creating variables without the caller seeing that
makes understanding what's going on significantly harder. Worse, that
magically appearing variable can hide a variable from a higher scope.
If the caller doesn't ask for the creation of the variable, then that
variable should be under the `spring` namespace. Of course that
(`spring.status`) would be more verbose than using a nested content
parameter, so it doesn't make sense in this case.

> Regards,
>
> Woonsan
>
>>
>>> Another question: is it okay to assume that I have a
>>> DefaultObjectWrapper when this directive is executed and throw an
>>> exception otherwise?
>>
>> At the moment it's enough to expect it to be an
>> ObjectWrapperAndUnwrapper. FreeMarkerServlet also requires that BTW.
>> I'm not sure if in the future expecting DefaultObjectWrapper will be
>> necessary, but hopefully not. (Custom JSP tag support expects a
>> DefaultObjectWrapper at the moment, for wrapping JSP functions.)
>>
 [snip]
> With nested content parameter it's also more obvious what's going on,
> and if you chose a shorter name it's not that verbose either:
>
>   <@spring.bind "user.name"; s>
> ${s.value}
>>>
>>> If I choose to use nested content parameter instead of having
>>> env.setVariable() calls, how can I get access to the parameter, s?
>>> Can I access it through any argument of the #execute() method in the
>>> Java code? Any example java code using nested content parameter?
>>
>> I'm not sure what you try to achieve. As the nested content parameter
>> is local to the nested content, similarly as a local variable is local
>> to the method body in Java, where do you want to access `s` from, and
>> why?
>>
>>> Thanks in advance,
>>>
>>> Woonsan
>>>
 [snip]

 Eh... of course the comment is outdated here. It will work in this
 case. `s` can't be hidden by anyone there, it wouldn't mater if we had
 <#local s = 'blah'> for example.

 --
 Thanks,
  Daniel Dekany

>>>
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>

-- 
Thanks,
 Daniel Dekany

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Tue, Aug 29, 2017 at 5:00 AM, Daniel Dekany  wrote:
> Tuesday, August 29, 2017, 5:25:31 AM, Woonsan Ko wrote:
>
>> Hi Daniel,
>>
>> Thanks for the remarks and hints! Please see my question inline.
>>
>> On Sat, Aug 26, 2017 at 4:50 AM, Daniel Dekany  wrote:
>>> Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:
>>>
>>> [snip]
   <#macro foo>
 <#local status = 'blah'>
 <@spring.bind "user.name">
   ${status.value} <#-- Means 'blah'.value, won't work -->
>>>
>>> To clarify, here I have assumed that spring.bind calls
>>> env.setVariable("status", ...) internally. Then the local with the
>>> same name shadows that tempolate-namespace scoped variable.
>>
>> It seems working with env.setVariable("status", ...):
>>
>> // Excerpt from
>> https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/BindDirective.java
>
> Looks good. But what are your thoughts on using a nested content
> parameter instead?

I'm sure I'm missing something or in misunderstandings. I want to try
the option using a nested content parameter instead, but I don't know
how to do that. ;-)
Ideally, <@spring.bind ... /> directive needs to set a local variable
called "status" or whatever (if the variable name can be given by a
nested content parameter) and developers should be able to use the
status variable ("status" or whatever) somehow inside the directive.
So, my assumption was, if the parameter is given to the directive, I
can probably fill in a variable somehow by resolving the bind status
object. I guess I'm totally ignorant on how nested content parameters
work with directives...

Regards,

Woonsan

>
>> Another question: is it okay to assume that I have a
>> DefaultObjectWrapper when this directive is executed and throw an
>> exception otherwise?
>
> At the moment it's enough to expect it to be an
> ObjectWrapperAndUnwrapper. FreeMarkerServlet also requires that BTW.
> I'm not sure if in the future expecting DefaultObjectWrapper will be
> necessary, but hopefully not. (Custom JSP tag support expects a
> DefaultObjectWrapper at the moment, for wrapping JSP functions.)
>
>>> [snip]
 With nested content parameter it's also more obvious what's going on,
 and if you chose a shorter name it's not that verbose either:

   <@spring.bind "user.name"; s>
 ${s.value}
>>
>> If I choose to use nested content parameter instead of having
>> env.setVariable() calls, how can I get access to the parameter, s?
>> Can I access it through any argument of the #execute() method in the
>> Java code? Any example java code using nested content parameter?
>
> I'm not sure what you try to achieve. As the nested content parameter
> is local to the nested content, similarly as a local variable is local
> to the method body in Java, where do you want to access `s` from, and
> why?
>
>> Thanks in advance,
>>
>> Woonsan
>>
>>> [snip]
>>>
>>> Eh... of course the comment is outdated here. It will work in this
>>> case. `s` can't be hidden by anyone there, it wouldn't mater if we had
>>> <#local s = 'blah'> for example.
>>>
>>> --
>>> Thanks,
>>>  Daniel Dekany
>>>
>>
>
> --
> Thanks,
>  Daniel Dekany
>

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Saturday, August 26, 2017, 10:44:03 AM, Daniel Dekany wrote:

[snip]
>   <#macro foo>
> <#local status = 'blah'>
> <@spring.bind "user.name">
>   ${status.value} <#-- Means 'blah'.value, won't work -->

To clarify, here I have assumed that spring.bind calls
env.setVariable("status", ...) internally. Then the local with the
same name shadows that tempolate-namespace scoped variable.

[snip]
> With nested content parameter it's also more obvious what's going on,
> and if you chose a shorter name it's not that verbose either:
>
>   <@spring.bind "user.name"; s>
> ${s.value} <#-- Means 'blah'.value, won't work -->
[snip]

Eh... of course the comment is outdated here. It will work in this
case. `s` can't be hidden by anyone there, it wouldn't mater if we had
<#local s = 'blah'> for example.

-- 
Thanks,
 Daniel Dekany

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Saturday, August 26, 2017, 10:17:55 AM, Daniel Dekany wrote:

> Saturday, August 26, 2017, 7:27:03 AM, Woonsan Ko wrote:
>
>> Hi Daniel,
>>
>> I've tried to write a directive to replace the spring:bind tag
>> library. But I get "IllegalStateException: Not executing macro body"
>> when invoking Environment#setLocalVariable(...).
>> <@spring.bind> is supposed to set a variable called 'status'. Could
>> you give me a hint on how to add a variable in a directive?
>
> The local variables are those that you could set with #local in a
> template, so setLocalVariable will only work if the directive is
> called from inside #macro or #function. I guess what you meant is
> setting a nested content variable

Actually, it's called a nested content *parameter*. It's like if the
directive passes an argument to the nested content, so on the caller
side it's like declaring a parameter name.

> (aka. loop variable), in but then
> the call syntax had to be `<@spring.bind "user.name"; status>...`.
> That is, the name of the target variable can't be specified by the
> directive, it's controlled by the caller. That's perhaps too
> inconvenient for this purpose though, as everyone just wants to call it
> "status". So certainly you should set a namespace-scoped (like
> #assign) or global (like #global) variable with setVariable or
> setGlobalVariable respectively. Of course, before setting them, they
> have to be read to store the old value, and then restored at the end.

Though the only pure solution is with nested content parameters...
Because for example here, `status` will be the local variable, as it
shadows the `status` set in a higher scope:

  <#macro foo>
<#local status = 'blah'>
<@spring.bind "user.name">
  ${status.value} <#-- Means 'blah'.value, won't work -->

  

With nested content parameter it's also more obvious what's going on,
and if you chose a shorter name it's not that verbose either:

  <@spring.bind "user.name"; s>
${s.value} <#-- Means 'blah'.value, won't work -->
  

That's the FreeMarkerish approach anyway. Setting variables from
inside a directive implementation, without the calling seeing that, is
generally a bad practice. If `status` were inside the `spring` hash,
then it would be fine, but that's certainly too verbose: 
`${spring.status.value}`.

>> Thanks in advance,
>>
>> Woonsan
>>
>>
>> On Thu, Aug 24, 2017 at 6:19 AM, Woonsan Ko  wrote:
>>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
 Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

 FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
 for argument validation and other exception creation. See
 AssertFailsDirective as an example. Of course, ideas for improving
 CallableUtils are highly welcome.

 BTW, certainly there are several TemplateFunctionModel and
 TemplateDirectiveModel implementations that could but don't yet use
 CallableUtils for argument validation. If you spot some, you may go
 ahead and improve them.
>>>
>>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>>> tickets, and it is really great! Really easy to extend it with
>>> TemplateCallableModel. Very simple but really powerful! I also saw
>>> IncludePage directive (as named "include_page")  in
>>> freemarker-servlet; it looks really straightforward.
>>> I'll try to write equivalent directives or functions from spring JSP
>>> Tag Library [1] and spring-form JSP Tag Library [2].
>>> By the way, I'm wondering what the best practices are in naming those
>>> models. Should it be better with 'form', 'spring_form', 'spring.form',
>>> or something else? Prefixing with something sounds safer to me.
>>>
>>> Regards,
>>>
>>> Woonsan
>>>
>>> [1] 
>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
>>> [2] 
>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>>

>> Besides, just to be absolutely clear, I would merge your current PR as
>> well, if it doesn't raise licensing issues, which is of course a
>> blocker.
>
> Sure, no worries. I was also under a concern about that and wanted to
> get feedbacks before doing too much. ;-)
>
> Regards,
>
> Woonsan
>
>>
>>
>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>
>>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  
>>> wrote:
 The big problem is that spring.ftl is copyrighted by some of the

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

Hi Daniel,

I've tried to write a directive to replace the spring:bind tag
library. But I get "IllegalStateException: Not executing macro body"
when invoking Environment#setLocalVariable(...).
<@spring.bind> is supposed to set a variable called 'status'. Could
you give me a hint on how to add a variable in a directive?

Thanks in advance,

Woonsan


On Thu, Aug 24, 2017 at 6:19 AM, Woonsan Ko  wrote:
> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
>> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
 If you are going to implement these directly as
 TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
 wait until I merge at least the FREEMARKER-63 PR... probably also
 FREEMARKER-64. I will try to do that tonight. At least 63.
>>>
>>> OK, I'll watch and wait for that. :-)
>>
>> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
>> for argument validation and other exception creation. See
>> AssertFailsDirective as an example. Of course, ideas for improving
>> CallableUtils are highly welcome.
>>
>> BTW, certainly there are several TemplateFunctionModel and
>> TemplateDirectiveModel implementations that could but don't yet use
>> CallableUtils for argument validation. If you spot some, you may go
>> ahead and improve them.
>
> Thank you so much! I've briefly browsed the PRs linked from the JIRA
> tickets, and it is really great! Really easy to extend it with
> TemplateCallableModel. Very simple but really powerful! I also saw
> IncludePage directive (as named "include_page")  in
> freemarker-servlet; it looks really straightforward.
> I'll try to write equivalent directives or functions from spring JSP
> Tag Library [1] and spring-form JSP Tag Library [2].
> By the way, I'm wondering what the best practices are in naming those
> models. Should it be better with 'form', 'spring_form', 'spring.form',
> or something else? Prefixing with something sounds safer to me.
>
> Regards,
>
> Woonsan
>
> [1] 
> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
> [2] 
> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>
>>
 Besides, just to be absolutely clear, I would merge your current PR as
 well, if it doesn't raise licensing issues, which is of course a
 blocker.
>>>
>>> Sure, no worries. I was also under a concern about that and wanted to
>>> get feedbacks before doing too much. ;-)
>>>
>>> Regards,
>>>
>>> Woonsan
>>>


 Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:

> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
>> The big problem is that spring.ftl is copyrighted by some of the
>> Spring authors (or the Spring project as a whole - it's not clear). So
>> certainly we can't just copy it. It has to be reimplemented without
>> looking at the source, or something absurd like that. Perhaps the best
>> is to start out from the spring JSP taglib, as that's the most widely
>> used templating solution (I assume), so certainly that's the one where
>> all the features are exposed.
>>
>> I wonder if using #import + FTL is the best way of adding
>> framework-level functionality that's used by a lot of people. It's
>> surely an OK way, but it's not the highest performance way. The other
>> way is using a shared variable (or some other kind of commonly visible
>> variable) and implement the library in Java using
>> TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
>> convenient than doing it in FTL, but it has to be done once, while you
>> save some resources everywhere where it's used. Though as most of
>> these macros/functions are quite simple, I don't think the performance
>> difference matters much. But, it also avoids the legal issue above. I
>> mean, many of these function/macros are so trivial, that it's hard to
>> implement them on a different way in FTL than as it is in the Spring
>> source code, but if you implement them in Java, then it's much harder
>> to accuse anyone with stealing. (A minor annoyance right now is that
>> that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
>> FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
>> enough shape soon. And see other thread; input is welcome!)
>>
>> As of template aliases, at the first glance that's fine. Note that
>> there's MultiTemplateLoader which does something similar, but I assume
>> it would be less neat (and/or slower) to do this with that. (But if
>> the spring functionality won't be #import-ed after all (as above), the
>> whole thing can become unnecessary...)
>
> Thank you very much for sharing your insights. Greatly helpful advice.
> I 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany wrote:

> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:
>
>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
>>> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>>>
 On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
> If you are going to implement these directly as
> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
> wait until I merge at least the FREEMARKER-63 PR... probably also
> FREEMARKER-64. I will try to do that tonight. At least 63.

 OK, I'll watch and wait for that. :-)
>>>
>>> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
>>> for argument validation and other exception creation. See
>>> AssertFailsDirective as an example. Of course, ideas for improving
>>> CallableUtils are highly welcome.
>>>
>>> BTW, certainly there are several TemplateFunctionModel and
>>> TemplateDirectiveModel implementations that could but don't yet use
>>> CallableUtils for argument validation. If you spot some, you may go
>>> ahead and improve them.
>>
>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>> tickets, and it is really great!

Though you better look at the examples in the 3.0 branch, because
FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
I shouldn't do that.)

>> Really easy to extend it with
>> TemplateCallableModel. Very simple but really powerful! I also saw
>> IncludePage directive (as named "include_page")  in
>> freemarker-servlet; it looks really straightforward.
>> I'll try to write equivalent directives or functions from spring JSP
>> Tag Library [1] and spring-form JSP Tag Library [2].
>
> Certainly quite a few changes will be needed compared to the JSP
> taglib. One such question if when and how escaping related
> functionality will appear, as escaping is a core facility in FTL.
> Also there are strange things like ``.
> I'm not sure why that isn't a function (used like
> )...

With correct JSP syntax that actually would be

  

if spring:url was a function. So it's kind of understandable that they
rather go with

  

But in FreeMarker it would be just:

  <#assign v = spring.url("somePath")>

or if you want to print it into the HTML:

  

So this was a case where what's a custom tag in JSP should be a
function in FreeMarker, not a directive.

> Also note that in FTL you can have positional parameters for
> directives, and named parameters for functions.

Usually, if a directive has a required parameter, whose meaning is
obvious for almost anybody, then that should be a positional
parameter. A very clear case of this is <#if something>. A less clear
case, but still maybe a good idea is making the "path" parameter of
form:input, form:label etc. positional:


  <@form.label "contactPerson">Contact person
  <@form.input "contactPerson"/>


I think anyone who knows even a little about Spring forms will know
that "contactPerson" is the property name in the backing form bean. Or
if not, path="contactPerson" is not much more helpful either.

Another place where FreeMarker differs from the approach of the Spring
JSP tags is when you refer to a value of the model (or to any Servlet
attribute). Like, you have an "employee" bean in the Spring Model, and
as far as I see in JSP you are supposed to bind that to a form like
this:

  

While technically possible, that's quote alien from FreeMarker. If the
directive wants to do something with the `emloyee` object, then pass
the object itself to it as argument, not the name of it. Like this:

  <@form.form action="/storeEmployee" model=employee>

Unless, the `form` directive indeed has to know the *name* of the
variable, as opposed to just the value of it... I'm not sure if that's
the case here. But I have seen this patter a few times in JSP (pass
the name of something instead of the thing itself), and had the
feeling that often it's just to avoid the more noisy
`model="${employee}"` syntax. FreeMarker has no such problem, as it's
just `model=employee` there, which is even less verbose than passing
the name of the variable.

> Also that a value can be both a function and a directive; maybe
> useful for message printing. If called like a function, it returns a
> string, if called like a tag, it prints the message without
> escaping... maybe.

So that practically means that these two will be equivalent:

  <@spring.message "foo" />

  ${spring.message("foo")?noEsc}

Now this is maybe too confusing for most users and thus is a bad idea.
But if spring.message will only have one type, then that's surely
function, not directive (unlike in the FM2 Spring integration).

Something that would be interesting if the spring.message function can
somehow tell if a message is plain text or HTML. Like you can
configure which messages are HTML on name patterns (or a content
pattern, like all HTML values start with ""). After all, 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko wrote:

> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany  wrote:
>> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
>>
>>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
 If you are going to implement these directly as
 TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
 wait until I merge at least the FREEMARKER-63 PR... probably also
 FREEMARKER-64. I will try to do that tonight. At least 63.
>>>
>>> OK, I'll watch and wait for that. :-)
>>
>> FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
>> for argument validation and other exception creation. See
>> AssertFailsDirective as an example. Of course, ideas for improving
>> CallableUtils are highly welcome.
>>
>> BTW, certainly there are several TemplateFunctionModel and
>> TemplateDirectiveModel implementations that could but don't yet use
>> CallableUtils for argument validation. If you spot some, you may go
>> ahead and improve them.
>
> Thank you so much! I've briefly browsed the PRs linked from the JIRA
> tickets, and it is really great! Really easy to extend it with
> TemplateCallableModel. Very simple but really powerful! I also saw
> IncludePage directive (as named "include_page")  in
> freemarker-servlet; it looks really straightforward.
> I'll try to write equivalent directives or functions from spring JSP
> Tag Library [1] and spring-form JSP Tag Library [2].

Certainly quite a few changes will be needed compared to the JSP
taglib. One such question if when and how escaping related
functionality will appear, as escaping is a core facility in FTL.
Also there are strange things like ``.
I'm not sure why that isn't a function (used like
)...

Also note that in FTL you can have positional parameters for
directives, and named parameters for functions. Also that a value can
be both a function and a directive; maybe useful for message printing.
If called like a function, it returns a string, if called like a tag,
it prints the message without escaping... maybe.

> By the way, I'm wondering what the best practices are in naming those
> models. Should it be better with 'form', 'spring_form', 'spring.form',
> or something else? Prefixing with something sounds safer to me.

In the templates they should be accessible as <@spring.bind ...> and
such. In the case of the form tags, as it's in a separate namespace in
JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100%
sure if its practical the structure of the JSP taglibs so closely, and
maybe we could just go with <@spring.input ...>. I don't know.)

> Regards,
>
> Woonsan
>
> [1]
> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
> [2]
> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>
>>
 Besides, just to be absolutely clear, I would merge your current PR as
 well, if it doesn't raise licensing issues, which is of course a
 blocker.
>>>
>>> Sure, no worries. I was also under a concern about that and wanted to
>>> get feedbacks before doing too much. ;-)
>>>
>>> Regards,
>>>
>>> Woonsan
>>>


 Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:

> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
>> The big problem is that spring.ftl is copyrighted by some of the
>> Spring authors (or the Spring project as a whole - it's not clear). So
>> certainly we can't just copy it. It has to be reimplemented without
>> looking at the source, or something absurd like that. Perhaps the best
>> is to start out from the spring JSP taglib, as that's the most widely
>> used templating solution (I assume), so certainly that's the one where
>> all the features are exposed.
>>
>> I wonder if using #import + FTL is the best way of adding
>> framework-level functionality that's used by a lot of people. It's
>> surely an OK way, but it's not the highest performance way. The other
>> way is using a shared variable (or some other kind of commonly visible
>> variable) and implement the library in Java using
>> TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
>> convenient than doing it in FTL, but it has to be done once, while you
>> save some resources everywhere where it's used. Though as most of
>> these macros/functions are quite simple, I don't think the performance
>> difference matters much. But, it also avoids the legal issue above. I
>> mean, many of these function/macros are so trivial, that it's hard to
>> implement them on a different way in FTL than as it is in the Spring
>> source code, but if you implement them in Java, then it's much harder
>> to accuse anyone with stealing. (A minor annoyance right now is that
>> that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
>> 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
for argument validation and other exception creation. See
AssertFailsDirective as an example. Of course, ideas for improving
CallableUtils are highly welcome.

BTW, certainly there are several TemplateFunctionModel and
TemplateDirectiveModel implementations that could but don't yet use
CallableUtils for argument validation. If you spot some, you may go
ahead and improve them.

>> Besides, just to be absolutely clear, I would merge your current PR as
>> well, if it doesn't raise licensing issues, which is of course a
>> blocker.
>
> Sure, no worries. I was also under a concern about that and wanted to
> get feedbacks before doing too much. ;-)
>
> Regards,
>
> Woonsan
>
>>
>>
>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>
>>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
 The big problem is that spring.ftl is copyrighted by some of the
 Spring authors (or the Spring project as a whole - it's not clear). So
 certainly we can't just copy it. It has to be reimplemented without
 looking at the source, or something absurd like that. Perhaps the best
 is to start out from the spring JSP taglib, as that's the most widely
 used templating solution (I assume), so certainly that's the one where
 all the features are exposed.

 I wonder if using #import + FTL is the best way of adding
 framework-level functionality that's used by a lot of people. It's
 surely an OK way, but it's not the highest performance way. The other
 way is using a shared variable (or some other kind of commonly visible
 variable) and implement the library in Java using
 TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
 convenient than doing it in FTL, but it has to be done once, while you
 save some resources everywhere where it's used. Though as most of
 these macros/functions are quite simple, I don't think the performance
 difference matters much. But, it also avoids the legal issue above. I
 mean, many of these function/macros are so trivial, that it's hard to
 implement them on a different way in FTL than as it is in the Spring
 source code, but if you implement them in Java, then it's much harder
 to accuse anyone with stealing. (A minor annoyance right now is that
 that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
 FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
 enough shape soon. And see other thread; input is welcome!)

 As of template aliases, at the first glance that's fine. Note that
 there's MultiTemplateLoader which does something similar, but I assume
 it would be less neat (and/or slower) to do this with that. (But if
 the spring functionality won't be #import-ed after all (as above), the
 whole thing can become unnecessary...)
>>>
>>> Thank you very much for sharing your insights. Greatly helpful advice.
>>> I agree that it might be better with template model(s) rather than
>>> library FTL in various aspects.
>>> Let me try with that approach again and let you know soon with a new PR.
>>>
>>> Thank again,
>>>
>>> Woonsan
>>>


 Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA) wrote:

>
> [
> https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115649#comment-16115649
>  ]
>
> ASF GitHub Bot commented on FREEMARKER-55:
> --
>
> GitHub user woonsan opened a pull request:
>
> https://github.com/apache/incubator-freemarker/pull/31
>
> FREEMARKER-55: spring.ftl marco lib support
>
> - Support <#import "/spring.ftl" as spring> like Spring Framework 
> does.
> - By default, the system lib from /spring.ftl is read from the
> specific classpath, not from app's template path.
>The system template aliases map can be customized through
> SpringResourceTemplateLoader.systemTemplateAliases property.
> - The same macros and functions are defined in /spring.ftl as
> Spring Framework's, with syntax changes to comply with FM3.
> - Note: As the system template lib support is handled by
> SpringTemplateLoader in this PR, it means developers should always
> use SpringTemplateLoader directly or indirectly in order to use the
> system macro library. Please review this 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

OK, so 63 and 64 is done.

65, which is the utility to help validating arguments and such, is
not. But for now, there's a very simple internal (and hopefully
temporal...) utility, org.apache.freemarker.core._CallableUtils, which
you can use and extend as needed. (I can't work on FM for at least two
days now.)

>> Besides, just to be absolutely clear, I would merge your current PR as
>> well, if it doesn't raise licensing issues, which is of course a
>> blocker.
>
> Sure, no worries. I was also under a concern about that and wanted to
> get feedbacks before doing too much. ;-)
>
> Regards,
>
> Woonsan
>
>>
>>
>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>
>>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
 The big problem is that spring.ftl is copyrighted by some of the
 Spring authors (or the Spring project as a whole - it's not clear). So
 certainly we can't just copy it. It has to be reimplemented without
 looking at the source, or something absurd like that. Perhaps the best
 is to start out from the spring JSP taglib, as that's the most widely
 used templating solution (I assume), so certainly that's the one where
 all the features are exposed.

 I wonder if using #import + FTL is the best way of adding
 framework-level functionality that's used by a lot of people. It's
 surely an OK way, but it's not the highest performance way. The other
 way is using a shared variable (or some other kind of commonly visible
 variable) and implement the library in Java using
 TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
 convenient than doing it in FTL, but it has to be done once, while you
 save some resources everywhere where it's used. Though as most of
 these macros/functions are quite simple, I don't think the performance
 difference matters much. But, it also avoids the legal issue above. I
 mean, many of these function/macros are so trivial, that it's hard to
 implement them on a different way in FTL than as it is in the Spring
 source code, but if you implement them in Java, then it's much harder
 to accuse anyone with stealing. (A minor annoyance right now is that
 that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
 FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
 enough shape soon. And see other thread; input is welcome!)

 As of template aliases, at the first glance that's fine. Note that
 there's MultiTemplateLoader which does something similar, but I assume
 it would be less neat (and/or slower) to do this with that. (But if
 the spring functionality won't be #import-ed after all (as above), the
 whole thing can become unnecessary...)
>>>
>>> Thank you very much for sharing your insights. Greatly helpful advice.
>>> I agree that it might be better with template model(s) rather than
>>> library FTL in various aspects.
>>> Let me try with that approach again and let you know soon with a new PR.
>>>
>>> Thank again,
>>>
>>> Woonsan
>>>


 Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA) wrote:

>
> [
> https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115649#comment-16115649
>  ]
>
> ASF GitHub Bot commented on FREEMARKER-55:
> --
>
> GitHub user woonsan opened a pull request:
>
> https://github.com/apache/incubator-freemarker/pull/31
>
> FREEMARKER-55: spring.ftl marco lib support
>
> - Support <#import "/spring.ftl" as spring> like Spring Framework 
> does.
> - By default, the system lib from /spring.ftl is read from the
> specific classpath, not from app's template path.
>The system template aliases map can be customized through
> SpringResourceTemplateLoader.systemTemplateAliases property.
> - The same macros and functions are defined in /spring.ftl as
> Spring Framework's, with syntax changes to comply with FM3.
> - Note: As the system template lib support is handled by
> SpringTemplateLoader in this PR, it means developers should always
> use SpringTemplateLoader directly or indirectly in order to use the
> system macro library. Please review this decision.
> - TODOs: review/test/refine each macro and functions in spring.ftl.
>
> You can merge this pull request into a Git 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Daniel Dekany]

Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:

> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)

I have merged those, but two things are still missing:
- The functions calls syntax still only supports positional arguments. 
(Directives
  are fully functional.)
- I will have to add some utility for argument validation/extraction
  (FREEMARKER-65). Until that, any totally simplistic solution
  suffices, as it will be replaced anyway.

I don't yet know when will I have time to address these, but probably
within a few days.

(In case you have wondered why your PR was red on Travis, it was an
issue caused by changes they have made in the Travis environment, and
is fixed now.)

>> Besides, just to be absolutely clear, I would merge your current PR as
>> well, if it doesn't raise licensing issues, which is of course a
>> blocker.
>
> Sure, no worries. I was also under a concern about that and wanted to
> get feedbacks before doing too much. ;-)
>
> Regards,
>
> Woonsan
>
>>
>>
>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>
>>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
 The big problem is that spring.ftl is copyrighted by some of the
 Spring authors (or the Spring project as a whole - it's not clear). So
 certainly we can't just copy it. It has to be reimplemented without
 looking at the source, or something absurd like that. Perhaps the best
 is to start out from the spring JSP taglib, as that's the most widely
 used templating solution (I assume), so certainly that's the one where
 all the features are exposed.

 I wonder if using #import + FTL is the best way of adding
 framework-level functionality that's used by a lot of people. It's
 surely an OK way, but it's not the highest performance way. The other
 way is using a shared variable (or some other kind of commonly visible
 variable) and implement the library in Java using
 TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
 convenient than doing it in FTL, but it has to be done once, while you
 save some resources everywhere where it's used. Though as most of
 these macros/functions are quite simple, I don't think the performance
 difference matters much. But, it also avoids the legal issue above. I
 mean, many of these function/macros are so trivial, that it's hard to
 implement them on a different way in FTL than as it is in the Spring
 source code, but if you implement them in Java, then it's much harder
 to accuse anyone with stealing. (A minor annoyance right now is that
 that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
 FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
 enough shape soon. And see other thread; input is welcome!)

 As of template aliases, at the first glance that's fine. Note that
 there's MultiTemplateLoader which does something similar, but I assume
 it would be less neat (and/or slower) to do this with that. (But if
 the spring functionality won't be #import-ed after all (as above), the
 whole thing can become unnecessary...)
>>>
>>> Thank you very much for sharing your insights. Greatly helpful advice.
>>> I agree that it might be better with template model(s) rather than
>>> library FTL in various aspects.
>>> Let me try with that approach again and let you know soon with a new PR.
>>>
>>> Thank again,
>>>
>>> Woonsan
>>>


 Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA) wrote:

>
> [
> https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115649#comment-16115649
>  ]
>
> ASF GitHub Bot commented on FREEMARKER-55:
> --
>
> GitHub user woonsan opened a pull request:
>
> https://github.com/apache/incubator-freemarker/pull/31
>
> FREEMARKER-55: spring.ftl marco lib support
>
> - Support <#import "/spring.ftl" as spring> like Spring Framework 
> does.
> - By default, the system lib from /spring.ftl is read from the
> specific classpath, not from app's template path.
>The system template aliases map can be customized through
> SpringResourceTemplateLoader.systemTemplateAliases property.
> - The same macros and functions are defined in /spring.ftl as
> Spring Framework's, with syntax changes to comply with FM3.
> - Note: As the system template lib support is handled by
> SpringTemplateLoader in this PR, it means developers should 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany  wrote:
> If you are going to implement these directly as
> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
> wait until I merge at least the FREEMARKER-63 PR... probably also
> FREEMARKER-64. I will try to do that tonight. At least 63.

OK, I'll watch and wait for that. :-)

>
> Besides, just to be absolutely clear, I would merge your current PR as
> well, if it doesn't raise licensing issues, which is of course a
> blocker.

Sure, no worries. I was also under a concern about that and wanted to
get feedbacks before doing too much. ;-)

Regards,

Woonsan

>
>
> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>
>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
>>> The big problem is that spring.ftl is copyrighted by some of the
>>> Spring authors (or the Spring project as a whole - it's not clear). So
>>> certainly we can't just copy it. It has to be reimplemented without
>>> looking at the source, or something absurd like that. Perhaps the best
>>> is to start out from the spring JSP taglib, as that's the most widely
>>> used templating solution (I assume), so certainly that's the one where
>>> all the features are exposed.
>>>
>>> I wonder if using #import + FTL is the best way of adding
>>> framework-level functionality that's used by a lot of people. It's
>>> surely an OK way, but it's not the highest performance way. The other
>>> way is using a shared variable (or some other kind of commonly visible
>>> variable) and implement the library in Java using
>>> TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
>>> convenient than doing it in FTL, but it has to be done once, while you
>>> save some resources everywhere where it's used. Though as most of
>>> these macros/functions are quite simple, I don't think the performance
>>> difference matters much. But, it also avoids the legal issue above. I
>>> mean, many of these function/macros are so trivial, that it's hard to
>>> implement them on a different way in FTL than as it is in the Spring
>>> source code, but if you implement them in Java, then it's much harder
>>> to accuse anyone with stealing. (A minor annoyance right now is that
>>> that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
>>> FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
>>> enough shape soon. And see other thread; input is welcome!)
>>>
>>> As of template aliases, at the first glance that's fine. Note that
>>> there's MultiTemplateLoader which does something similar, but I assume
>>> it would be less neat (and/or slower) to do this with that. (But if
>>> the spring functionality won't be #import-ed after all (as above), the
>>> whole thing can become unnecessary...)
>>
>> Thank you very much for sharing your insights. Greatly helpful advice.
>> I agree that it might be better with template model(s) rather than
>> library FTL in various aspects.
>> Let me try with that approach again and let you know soon with a new PR.
>>
>> Thank again,
>>
>> Woonsan
>>
>>>
>>>
>>> Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA) wrote:
>>>

 [
 https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115649#comment-16115649
  ]

 ASF GitHub Bot commented on FREEMARKER-55:
 --

 GitHub user woonsan opened a pull request:

 https://github.com/apache/incubator-freemarker/pull/31

 FREEMARKER-55: spring.ftl marco lib support

 - Support <#import "/spring.ftl" as spring> like Spring Framework does.
 - By default, the system lib from /spring.ftl is read from the
 specific classpath, not from app's template path.
The system template aliases map can be customized through
 SpringResourceTemplateLoader.systemTemplateAliases property.
 - The same macros and functions are defined in /spring.ftl as
 Spring Framework's, with syntax changes to comply with FM3.
 - Note: As the system template lib support is handled by
 SpringTemplateLoader in this PR, it means developers should always
 use SpringTemplateLoader directly or indirectly in order to use the
 system macro library. Please review this decision.
 - TODOs: review/test/refine each macro and functions in spring.ftl.

 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/woonsan/incubator-freemarker 
 feature/FREEMARKER-55

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/incubator-freemarker/pull/31.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #31

 
 commit 

Re: (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

[Woonsan Ko]

On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany  wrote:
> The big problem is that spring.ftl is copyrighted by some of the
> Spring authors (or the Spring project as a whole - it's not clear). So
> certainly we can't just copy it. It has to be reimplemented without
> looking at the source, or something absurd like that. Perhaps the best
> is to start out from the spring JSP taglib, as that's the most widely
> used templating solution (I assume), so certainly that's the one where
> all the features are exposed.
>
> I wonder if using #import + FTL is the best way of adding
> framework-level functionality that's used by a lot of people. It's
> surely an OK way, but it's not the highest performance way. The other
> way is using a shared variable (or some other kind of commonly visible
> variable) and implement the library in Java using
> TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
> convenient than doing it in FTL, but it has to be done once, while you
> save some resources everywhere where it's used. Though as most of
> these macros/functions are quite simple, I don't think the performance
> difference matters much. But, it also avoids the legal issue above. I
> mean, many of these function/macros are so trivial, that it's hard to
> implement them on a different way in FTL than as it is in the Spring
> source code, but if you implement them in Java, then it's much harder
> to accuse anyone with stealing. (A minor annoyance right now is that
> that part of the FreeMarker API is not yet settled; see FREEMARKER-63,
> FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a good
> enough shape soon. And see other thread; input is welcome!)
>
> As of template aliases, at the first glance that's fine. Note that
> there's MultiTemplateLoader which does something similar, but I assume
> it would be less neat (and/or slower) to do this with that. (But if
> the spring functionality won't be #import-ed after all (as above), the
> whole thing can become unnecessary...)

Thank you very much for sharing your insights. Greatly helpful advice.
I agree that it might be better with template model(s) rather than
library FTL in various aspects.
Let me try with that approach again and let you know soon with a new PR.

Thank again,

Woonsan

>
>
> Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA) wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115649#comment-16115649
>>  ]
>>
>> ASF GitHub Bot commented on FREEMARKER-55:
>> --
>>
>> GitHub user woonsan opened a pull request:
>>
>> https://github.com/apache/incubator-freemarker/pull/31
>>
>> FREEMARKER-55: spring.ftl marco lib support
>>
>> - Support <#import "/spring.ftl" as spring> like Spring Framework does.
>> - By default, the system lib from /spring.ftl is read from the
>> specific classpath, not from app's template path.
>>The system template aliases map can be customized through
>> SpringResourceTemplateLoader.systemTemplateAliases property.
>> - The same macros and functions are defined in /spring.ftl as
>> Spring Framework's, with syntax changes to comply with FM3.
>> - Note: As the system template lib support is handled by
>> SpringTemplateLoader in this PR, it means developers should always
>> use SpringTemplateLoader directly or indirectly in order to use the
>> system macro library. Please review this decision.
>> - TODOs: review/test/refine each macro and functions in spring.ftl.
>>
>> You can merge this pull request into a Git repository by running:
>>
>> $ git pull https://github.com/woonsan/incubator-freemarker 
>> feature/FREEMARKER-55
>>
>> Alternatively you can review and apply these changes as the patch at:
>>
>> https://github.com/apache/incubator-freemarker/pull/31.patch
>>
>> To close this pull request, make a commit to your master/trunk branch
>> with (at least) the following in the commit message:
>>
>> This closes #31
>>
>> 
>> commit 8e0f33c419d982279d7fb22a9dfdc66f47abaf2c
>> Author: Woonsan Ko 
>> Date:   2017-07-14T15:27:17Z
>>
>> FREEMARKER-55: Renaming Freemarker to FreeMarker
>>
>> commit ec8d687d4ce2c0e1bb3e3ca073b139eacc198527
>> Author: Woonsan Ko 
>> Date:   2017-07-14T15:53:51Z
>>
>> Merge branch '3' into feature/FREEMARKER-55
>>
>> commit e7cb6f7cfc241689c85527971bf6e1ea7ced9127
>> Author: Woonsan Ko 
>> Date:   2017-07-14T17:57:29Z
>>
>> Merge branch '3' into feature/FREEMARKER-55
>>
>> commit c6eb09de91e57035c1e0e3c4d3490b3b96622bab
>> Author: Woonsan Ko 
>> Date:   2017-07-16T18:24:55Z
>>
>> Merge branch '3' into feature/FREEMARKER-55
>>
>> commit 870209fa8e0acd0bb3186053dfd549b5c758e37d
>> Author: Woonsan Ko 
>> Date:   2017-07-18T00:38:03Z
>>
>> Merge branch '3' into