On Thu, Sep 14, 2017 at 5:09 AM, Daniel Dekany <ddek...@apache.org> wrote:
> Thursday, September 14, 2017, 4:15:04 AM, Woonsan Ko wrote:
>
> [snip]
>>>> And, I'd like to ask about this example:
>>>>
>>>> <a class="userIdLink" href="${spring.url('/users/{userId}/',
>>>> userId=user.id?string)}">${user.id!}</a>
>>>>
>>>> The reason why I had to use ?string built-in was that user.id returns
>>>> a TemplateNumberModel, while the function is expecting a string
>>>> argument.
>>>
>>> But do we really have to do that conversion? MessageFormat allows
>>> Object parameters, also it has its own mini template language, which
>>> can, among others, format numbers. I don't think we should interfere
>>> with that, at least not by default.
>>
>> The example is about spring.url function, not spring.message function.
>
> Ugh... sorry. So then the situation is different. We should convert
> automatically to string, but definitely not with
> Environment.formatXxx, as that formats for human audience, so you can
> end up with `id=1,234,567` instead of `id=1234567`. Number formatted
> for URL-s should always follow computer format. For boolean it should
> be clearly true/false (so yet again we don't use the current boolean
> format).
>
> Temporal values is a problem, because they have no universally
> accepted computer format. Perhaps we should format them according to
> the ISO standard (with an XSD compliant variation of it). _DateUtils
> can do that. But for timestamps, seconds or millis since the epoch is
> also often used. I'm not sure if there's a convention in the
> Java(/Spring) ecosystem that prevalent enough. Probably we should just
> throw a helpful exception in which we tell the user to format the
> thing manually, for example with ?long or ?string.iso or ?string.xs.
>
> Then there are lists and maps (sequences and hashes as FM calls
> them... until I change it in FM3). I assume those should be just
> errors. (I don't know if the JSP taglib has some speciality for them.
> For example for lists, I would think that if I write `tag={tag}` and
> the value is a list, then they should generate
> `tag=val1&tag=val2&tag=valN`.)Thanks again for the insights! I've made a new pull request to address those: - https://github.com/apache/incubator-freemarker/pull/36 The spring.url function now converts only TemplateStringModel, TemplateNumberModel and TemplateBooleanModel and throw exception for other types with an error message. AFAIK, JSP taglib doesn't do much for list or map. It probably uses #toString(). And, since both <c:param/> and <spring:param/> in <c:url/> and <spring:url/> accepts only String parameter name/value pair, I don't think there's anything more. Please take another look at it. Kind regards, Woonsan > >> The former one takes strings only for both param name and param value >> (<spring:param> tags inside <spring:url> tag). The latter one takes >> Object array, single object or comma separated string >> (<spring:message> and <spring:argument>). >> In spring.url function, it should be more convenient if we can take >> TemplateNumberModel named parameters without '?string' for instance. >> >>> >>>> But, if there's a way to convert a TemplateNumberModel to a string, >>>> then I think the function might be more convenient without having to >>>> use ?string. >>>> Do you think if there's a way to improve this (allowing somethings >>>> like TemplateNumberModel in this kind of string-expected values), or >>>> ?string is a good way? Or any other options? >>> >>> If those still have to be strings, then surely we don't want users to >>> write ?string everywhere, because that's repetative and so we should >>> do it instead. I have added Environment.formatToPlainText; you can use >>> that for now in case the parameter is not a TemplateStringModel. (I >>> guess this method should be backported to FM2 as well.) >> >> Thanks for the tip! I've updated the PR to use >> Environment.formatToPlainText in UrlFunction as well if a parameter >> value is not TemplateStringModel. >> >>> >>> BTW, I wonder that if the messages contains HTML, and hence it's >>> printed by FreeMarker without escaping, what ensures that the >>> substituted parameters are HTML-escaped. That's a security issue, so >>> we must find an answer to that, when we will support returning >>> MarkupOutputModel-s. >> >> Good point. I have assumed that developers need to escape the result >> by themselves, but yes, we will need more considerations with >> examples. >> >> Kind regards, >> >> Woonsan >> >>> >>>> Kind regards, >>>> >>>> Woonsan >>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Woonsan >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Woonsan >>>>>>> >>>>>>>> >>>>>>>>> (ref: >>>>>>>>> https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl) >>>>>>>>> >>>>>>>>> Still need to add an example using 'message' named parameter. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Woonsan >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> look at `spring.message("foo")`, I think you would intuitively think >>>>>>>>>>> that it prints the "foo" message. As of the others, I guess we don't >>>>>>>>>>> need "text" as you can write ${spring.message("foo")!'default'}, nor >>>>>>>>>>> do we need the xxxEscape parameters, as we have HTML auto-escaping >>>>>>>>>>> and >>>>>>>>>>> `spring.message("foo")?jsString`. >>>>>>>>>> >>>>>>>>>> Oh, cool! I didn't know we have ?jsString. Perfect. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Something that would be interesting if the spring.message >>>>>>>>>>>>> function can >>>>>>>>>>>>> somehow tell if a message is plain text or HTML. Like you can >>>>>>>>>>>>> configure which messages are HTML on name patterns (or a content >>>>>>>>>>>>> pattern, like all HTML values start with "<span>"). After all, >>>>>>>>>>>>> without >>>>>>>>>>>>> such a rule, how do the developers themselves know if a message >>>>>>>>>>>>> should >>>>>>>>>>>>> be HTML or plain text. Hopefully the have some exact policy for >>>>>>>>>>>>> that. >>>>>>>>>>>>> If spring.message knows that rule too, then for HTML messages it >>>>>>>>>>>>> should return a TemplateMarkupOutputModel instead of a string, so >>>>>>>>>>>>> it >>>>>>>>>>>>> will be automatically non-escaped. Then people can just write >>>>>>>>>>>>> ${spring.message("foo")} without worrying about `?noEsc`. And >>>>>>>>>>>>> then we >>>>>>>>>>>>> certainly don't need the directive "overload" either. >>>>>>>>>>>> >>>>>>>>>>>> As far as I know, MessageTag extends HtmlEscapingAwareTag which has >>>>>>>>>>>> the following javadoc: >>>>>>>>>>>> >>>>>>>>>>>> * <p>Provides a "htmlEscape" property for explicitly specifying >>>>>>>>>>>> whether to >>>>>>>>>>>> * apply HTML escaping. If not set, a page-level default (e.g. >>>>>>>>>>>> from the >>>>>>>>>>>> * HtmlEscapeTag) or an application-wide default (the >>>>>>>>>>>> "defaultHtmlEscape" >>>>>>>>>>>> * context-param in {@code web.xml}) is used. >>>>>>>>>>> >>>>>>>>>>> So then it seems we indeed need some spring library configuration >>>>>>>>>>> parameter that associates an output format (as in >>>>>>>>>>> http://freemarker.org/docs/dgui_misc_autoescaping.html) to each >>>>>>>>>>> message, based on patterns. By default everything should be just >>>>>>>>>>> plain >>>>>>>>>>> text, to be on the safe side (i.e., auto-escaping will happen for >>>>>>>>>>> them, because ${} does that). The equivalent of "defaultHtmlEscape" >>>>>>>>>>> being on is that you assoicate "HTML" output format to all messages. >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This also reinforces that, at least in the first iteration, >>>>>>>>>>> spring.message should be function only, not a directive. >>>>>>>>>>> `${spring.message("foo")}` isn't more verbose than >>>>>>>>>>> `<@spring.message "foo" />` anyway. >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> BTW, I think it may worth having a special syntax for message >>>>>>>>>>> insertion in the template language. For example, >>>>>>>>>>> %{label.greet user, today} would be a syntactical sugar for >>>>>>>>>>> ${someframewok.message('label.greet', user, today)}. But that's >>>>>>>>>>> another topic. >>>>>>>>>> >>>>>>>>>> Sounds promising! >>>>>>>>>> >>>>>>>>>> Woonsan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Woonsan >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> I meant: "if it's practical to follow the structure of the JSP >>>>>>>>>>>>> taglibs >>>>>>>>>>>>> so closely" >>>>>>>>>>>>> >>>>>>>>>>>>>> maybe we could just go with <@spring.input ...>. I don't know.) >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Daniel Dekany >>>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Daniel Dekany >>>>> >>>> >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >> > > -- > Thanks, > Daniel Dekany >
