On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany <[email protected]> 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 <[email protected]> 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&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 <[email protected]>
>>>> Date:   2017-07-14T15:27:17Z
>>>>
>>>>     FREEMARKER-55: Renaming Freemarker to FreeMarker
>>>>
>>>> commit ec8d687d4ce2c0e1bb3e3ca073b139eacc198527
>>>> Author: Woonsan Ko <[email protected]>
>>>> Date:   2017-07-14T15:53:51Z
>>>>
>>>>     Merge branch '3' into feature/FREEMARKER-55
>>>>
>>>> commit e7cb6f7cfc241689c85527971bf6e1ea7ced9127
>>>> Author: Woonsan Ko <[email protected]>
>>>> Date:   2017-07-14T17:57:29Z
>>>>
>>>>     Merge branch '3' into feature/FREEMARKER-55
>>>>
>>>> commit c6eb09de91e57035c1e0e3c4d3490b3b96622bab
>>>> Author: Woonsan Ko <[email protected]>
>>>> Date:   2017-07-16T18:24:55Z
>>>>
>>>>     Merge branch '3' into feature/FREEMARKER-55
>>>>
>>>> commit 870209fa8e0acd0bb3186053dfd549b5c758e37d
>>>> Author: Woonsan Ko <[email protected]>
>>>> Date:   2017-07-18T00:38:03Z
>>>>
>>>>     Merge branch '3' into feature/FREEMARKER-55
>>>>
>>>> commit 4481406a2f4eeb30d6d044a4ac158efab7ba7a7b
>>>> Author: Woonsan Ko <[email protected]>
>>>> Date:   2017-08-06T01:28:54Z
>>>>
>>>>     Merge branch '3' into feature/FREEMARKER-55
>>>>
>>>> commit fcd9e672ec515e3042bc5efd229b7d12c23e7d88
>>>> Author: Woonsan Ko <[email protected]>
>>>> 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
>>>
>>
>
> --
> Thanks,
>  Daniel Dekany
>

Reply via email to