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 <woon...@apache.org> wrote: > On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany <ddek...@apache.org> wrote: >> Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote: >> >>> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany <ddek...@apache.org> 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 <ddek...@freemail.hu> 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 <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 >>>>>> >>>>> >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>> >> >> -- >> Thanks, >> Daniel Dekany >>
