On Tue, Sep 5, 2017 at 8:58 AM, Woonsan Ko <woon...@apache.org> wrote:
> 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.
I've proposed a PR for tags defined in spring.tld for now:
https://github.com/apache/incubator-freemarker/pull/34
I'll continue to replace tags in form.tld.
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
>>
