Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote: > 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. :-)
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 <[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 >> > -- Thanks, Daniel Dekany
