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

2017-08-07 Thread 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

2017-08-07 Thread 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

2017-08-07 Thread 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