Saturday, September 2, 2017, 5:03:51 AM, Woonsan Ko wrote: > On Thu, Aug 24, 2017 at 3:53 AM, Daniel Dekany <ddek...@apache.org> wrote: >> Thursday, August 24, 2017, 6:19:29 AM, Woonsan Ko 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]. >> >> Certainly quite a few changes will be needed compared to the JSP >> taglib. One such question if when and how escaping related >> functionality will appear, as escaping is a core facility in FTL. >> Also there are strange things like `<spring:url path=... var='v'>`. >> I'm not sure why that isn't a function (used like >> <c:set v=spring:ulr(path)>)... > > According to spring.tld, it's supposed to substitute the JSTL <c:url />> tag. And it has many optional parameters: context, var, scope, > htmlEscape, javaScriptEscape. It was impossible to define a convenient > JSTL function instead. So, it makes sense in their perspective as JSP > taglibs. > Another thing is it can save the generated URL string into a variable > by setting 'var', so that you don't need to invoke the function > multiple times for the same URL.
They could just assign the return value of spring:url() to a variable for that. Though <c:set var="v" value="${spring:url("foo")}"/> is quite verbose for sure, but that's how the JSP syntax elsewhere too. <#assign v = spring.url("foo")> is significantly less verbose. > I personally think it gives convenience to developers if we provide > both a directive and function for the URL tag in FreeMarker. Since > FreeMarker supports optional position/named parameters, each option > would be easier to do. When is it more practical to call spring.url as directive than as a function? >> Also note that in FTL you can have positional parameters for >> directives, and named parameters for functions. Also that a value can >> be both a function and a directive; maybe useful for message printing. >> If called like a function, it returns a string, if called like a tag, >> it prints the message without escaping... maybe. >> >>> 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. >> >> In the templates they should be accessible as <@spring.bind ...> and >> such. In the case of the form tags, as it's in a separate namespace in >> JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100% >> sure if its practical the structure of the JSP taglibs so closely, and >> maybe we could just go with <@spring.input ...>. I don't know.) > > I personally prefer keeping a similar structure of the JSP taglibs as > possible, which could make developers easier to migrate. > So, <@spring.bind ...> and <@form.input ...> sound good to me. Sound got to me too. > Perhaps we can make the namespaces configurable through view > configurations. Though for now it's not needed. > Regards, > > Woonsan > >> >>> 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 >>>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany