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


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&focusedCommentId=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 <woon...@apache.org>
> Date:   2017-07-14T15:27:17Z
>
>     FREEMARKER-55: Renaming Freemarker to FreeMarker
>
> commit ec8d687d4ce2c0e1bb3e3ca073b139eacc198527
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-07-14T15:53:51Z
>
>     Merge branch '3' into feature/FREEMARKER-55
>
> commit e7cb6f7cfc241689c85527971bf6e1ea7ced9127
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-07-14T17:57:29Z
>
>     Merge branch '3' into feature/FREEMARKER-55
>
> commit c6eb09de91e57035c1e0e3c4d3490b3b96622bab
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-07-16T18:24:55Z
>
>     Merge branch '3' into feature/FREEMARKER-55
>
> commit 870209fa8e0acd0bb3186053dfd549b5c758e37d
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-07-18T00:38:03Z
>
>     Merge branch '3' into feature/FREEMARKER-55
>
> commit 4481406a2f4eeb30d6d044a4ac158efab7ba7a7b
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-08-06T01:28:54Z
>
>     Merge branch '3' into feature/FREEMARKER-55
>
> commit fcd9e672ec515e3042bc5efd229b7d12c23e7d88
> Author: Woonsan Ko <woon...@apache.org>
> Date:   2017-08-06T05:09:12Z
>
>     FREEMARKER-55: system template lib for spring app: spring.ftl.
>
> ----
>
>
>> FM3 freemarker-spring module, Web MVC support
>> ---------------------------------------------
>>
>>                 Key: FREEMARKER-55
>>                 URL: https://issues.apache.org/jira/browse/FREEMARKER-55
>>             Project: Apache Freemarker
>>          Issue Type: Task
>>    Affects Versions: 3.0.0
>>            Reporter: Daniel Dekany
>>
>> Add Spring "Web MVC framework" functionality to freemarker-spring.
>> This can be complex task (and the issue possibly has to be subdivided), as 
>> it involves things like:
>> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
>> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
>> looking into if it needs to be like that.
>> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
>> hard coded into {{ViewResolverRegistry}}, which we can't modify)
>> * Creating custom directives/methods to expose Spring features like the 
>> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
>> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
>> Depends on: FREEMARKER-54
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

-- 
Thanks,
 Daniel Dekany

Reply via email to