On Sun, Sep 3, 2017 at 7:55 AM, Daniel Dekany <ddek...@apache.org> wrote:
> Sunday, September 3, 2017, 6:29:54 AM, Woonsan Ko wrote:
>
>> On Sat, Sep 2, 2017 at 7:33 PM, Woonsan Ko <woon...@apache.org> wrote:
>>> On Sat, Sep 2, 2017 at 3:36 AM, Daniel Dekany <ddek...@apache.org> wrote:
>>>> Saturday, September 2, 2017, 5:24:11 AM, Woonsan Ko wrote:
>>>>
>>>>> On Thu, Aug 24, 2017 at 4:04 PM, Daniel Dekany <ddek...@apache.org> wrote:
>>>>>> Thursday, August 24, 2017, 9:53:11 AM, Daniel Dekany 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!
>>>>>>
>>>>>> Though you better look at the examples in the 3.0 branch, because
>>>>>> FREEMARKER-65 wasn't a PR; I have committed it directly there. (Maybe
>>>>>> I shouldn't do that.)
>>>>>>
>>>>>>>> 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)>)...
>>>>>>
>>>>>> With correct JSP syntax that actually would be
>>>>>>
>>>>>> <c:set var="v" value="${spring:url("somePath")}">
>>>>>>
>>>>>> if spring:url was a function. So it's kind of understandable that they
>>>>>> rather go with
>>>>>>
>>>>>> <spring:url path="somePath" var="v" />
>>>>>>
>>>>>> But in FreeMarker it would be just:
>>>>>>
>>>>>> <#assign v = spring.url("somePath")>
>>>>>>
>>>>>> or if you want to print it into the HTML:
>>>>>>
>>>>>> <a href="${spring.url("somePath")}">
>>>>>>
>>>>>> So this was a case where what's a custom tag in JSP should be a
>>>>>> function in FreeMarker, not a directive.
>>>>>>
>>>>>>> Also note that in FTL you can have positional parameters for
>>>>>>> directives, and named parameters for functions.
>>>>>>
>>>>>> Usually, if a directive has a required parameter, whose meaning is
>>>>>> obvious for almost anybody, then that should be a positional
>>>>>> parameter. A very clear case of this is <#if something>. A less clear
>>>>>> case, but still maybe a good idea is making the "path" parameter of
>>>>>> form:input, form:label etc. positional:
>>>>>>
>>>>>> <tr>
>>>>>> <td><@form.label "contactPerson">Contact person</@></td>
>>>>>> <td><@form.input "contactPerson"/></td>
>>>>>> </tr>
>>>>>>
>>>>>> I think anyone who knows even a little about Spring forms will know
>>>>>> that "contactPerson" is the property name in the backing form bean. Or
>>>>>> if not, path="contactPerson" is not much more helpful either.
>>>>>>
>>>>>> Another place where FreeMarker differs from the approach of the Spring
>>>>>> JSP tags is when you refer to a value of the model (or to any Servlet
>>>>>> attribute). Like, you have an "employee" bean in the Spring Model, and
>>>>>> as far as I see in JSP you are supposed to bind that to a form like
>>>>>> this:
>>>>>>
>>>>>> <form:form action="/storeEmployee" modelAttribute="employee">
>>>>>>
>>>>>> While technically possible, that's quote alien from FreeMarker. If the
>>>>>> directive wants to do something with the `emloyee` object, then pass
>>>>>> the object itself to it as argument, not the name of it. Like this:
>>>>>>
>>>>>> <@form.form action="/storeEmployee" model=employee>
>>>>>>
>>>>>> Unless, the `form` directive indeed has to know the *name* of the
>>>>>> variable, as opposed to just the value of it... I'm not sure if that's
>>>>>> the case here. But I have seen this patter a few times in JSP (pass
>>>>>> the name of something instead of the thing itself), and had the
>>>>>> feeling that often it's just to avoid the more noisy
>>>>>> `model="${employee}"` syntax. FreeMarker has no such problem, as it's
>>>>>> just `model=employee` there, which is even less verbose than passing
>>>>>> the name of the variable.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> So that practically means that these two will be equivalent:
>>>>>>
>>>>>> <@spring.message "foo" />
>>>>>>
>>>>>> ${spring.message("foo")?noEsc}
>>>>>>
>>>>>> Now this is maybe too confusing for most users and thus is a bad idea.
>>>>>> But if spring.message will only have one type, then that's surely
>>>>>> function, not directive (unlike in the FM2 Spring integration).
>>>>>
>>>>> <spring:message /> tag also has many optional parameters: message,
>>>>> code, arguments, argumentSeparator, text, var, scope, htmlEscape and
>>>>> javaScriptEscape. Without 'var' support by a directive, it means
>>>>> invoking the function for the same parameters every time. code means
>>>>> resource bundle key, text means default value if not found, and
>>>>> message means an argument for the Spring-specific
>>>>> MessageSourceResolvable. So, in this specific case, I don't know which
>>>>> one should take the positional parameter. Perhaps 'code'?
>>>>
>>>> Yes. That's the only required parameter to start with. Also, if you
>>>
>>> One problem is that 'code' is not required in spring tag. Perhaps
>>> someones are using the tag without 'code' in some cases.
>>> I assume the only positional parameter for 'code' in FTL function
>>> could be optional with default value being null, right?
>>
>> I've tried with the idea as spring.message function:
>> -
>> https://github.com/woonsan/incubator-freemarker/blob/feature/FREEMARKER-55-2/freemarker-spring/src/main/java/org/apache/freemarker/spring/model/MessageFunction.java
>
> An argument is a string exactly if it implements TemplateStringModel.
> Then TemplateStringModel.getAsString() returns the String object. It
> doesn't mater what does it wrap, if anything. Also, because of the
> toString(), the current code accepts any kind of object.
Thanks for the pointer!
I've replaced it with CallableUtils.getOptionalStringArgument(args,
CODE_PARAM_IDX, this).
>
> Also, for generating exceptions, CallableUtils should be used wherever
> possible.
Cool! Updated those accordingly, too.
>
>> It reads 'code' and message arguments from positional vargs, with no
>> predefined positional args since it should support 'message' named
>> parameter without 'code'.
>
> "code" is still a predefined positional argument (even if optional
> because of the named "message" param). After that there's a varargs
> parameter for the message parameters only.
>
>> For example,
>> <th>${spring.message("user.firstName")!}</th>
>> <p>${spring.message("user.form.message", user.firstName,
>> user.lastName, user.email)?html}</p>
>
> Note that `?html` is old-style, as we prefer HTML auto-escaping for a
> while. So we should use `?jsString` if we want to demonstrate explicit
> escaping.
Right. I updated the example simply to have <#ftl outputFormat="HTML">.
I'll move onto the rest of spring.tld tags and form.tld tags.
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
>
