[
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073381#comment-16073381
]
Daniel Dekany commented on FREEMARKER-55:
-----------------------------------------
Even if the existing Spring macros/function work now (haven't checked it), they
won't for very long, as the FM3 template language will become quite different.
So eventually we will have to rewrite them anyway.
As of switching {{freemarker-servlet}} to Servlet 3.0, I guess that's fine (and
then JSP switches to 2.2 too).
I have noticed that we depend on a very specific Spring version, 4.3.9.RELEASE.
Note sure if it was a conscious decision.
Will that be the minimum required version? 4.3.x is quite recent.
As of {{TaglibFactoryBuilder}}, since {{TaglibFactory}} is mutable, I'm not
sure how introducing {{TaglibFactoryBuilder}} helps at the moment. Yes,
there are some functionality there that wasn't public earlier, but technically,
that could have been added to {{TaglibFactory}}
as well. But, probably it would be nicer if {{TaglibFactory}} is immutable, and
then a builder is needed of course.
Also, I think it would be good to stick to the particular builder flavor that
we have introduced for {{Configuration}} and such.
(That is, {{Builder}} is a nested class that implements {{CommonBuilder}}, the
built object is immutable, etc.)
{{FreemarkerViewResolver}} exposing things like {{FreemarkerServlet}}: I don't
know what the Spring-ish way is. Exposing HTTP- and Servlet-specific objects to
FreeMarker templates stinks in general, but I know little about the Spring
front-end development reality, and thus if it's practical to expose them. In
the case of {{FreemarkerServlet}} it clearly was, as the goal was to help
integration with legacy JSP-based frameworks, where playing with these
Serlvet-specific objects in views was normal. Also, I don't know if Spring has
its own utilities to access these things (which it exposes to views), because
then we might don't want to duplicate that functionality.
I think we will be better of with
{{org.apache.freemarker.spring.SpringResourceTemplateLoader}}
than with
{{org.apache.freemarker.spring.templateresolver.SpringResourceTemplateLoader}}
(package name differs). The idea
is that, in general, classes people commonly use (in this case in the Spring
configuration) should be
in the root package of the module ({{org.apache.freemarker.spring}}). So both
{{ConfigurationFactoryBean}}
and {{SpringResourceTemplateLoader}} should be there (unless we will have much
more "templatresolver"-related classes).
Side note: As of {{<property name="settings">}} in the example, note that
unlike in FM2's spring integration, in reality that should only be used to
apply a piece of configuration that comes from a .properties file or other
externally provided {{Properties}} object. That is, almost never. We might
discover some things to improve if we try do things with the setter methods
only (like, creating the {{CacheStorage}} will be kind of awkward, and so might
need improvement).
Eventually, the short description changes should be added to
{{FM3-CHANGE-LOG.txt}}.
> 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)
