You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Daniel Dekany <dd...@apache.org> on 2017/07/04 15:04:20 UTC
Re: FM3 log categories (Was: Re: [FM3] Spring Framework Support)
Done, now we are just using
private static final Logger LOG = LoggerFactory.getLogger(TheClassYouAreIn.class);
everywhere.
Monday, June 19, 2017, 4:04:20 PM, Woonsan Ko wrote:
> On Mon, Jun 19, 2017 at 6:50 AM, Daniel Dekany <dd...@apache.org> wrote:
>> Monday, June 19, 2017, 7:03:33 AM, Woonsan Ko wrote:
>>
>>> On Sat, Jun 3, 2017 at 9:50 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>> I have created two issues for this. For the non-Web-MVC part:
>>>> https://issues.apache.org/jira/browse/FREEMARKER-54
>>>
>>> I've opened new PR today.
>>> In addition to the features described in the JIRA ticket, some minor were added:
>>> - VersionEditor was added in core as Spring allows to set a Version
>>> property value through a string instead by the PropertyEditor. This is
>>> convenient in XML bean settings.
>>> - baseLocation property was added (null by default) in
>>> SpringResourceTemplateLoader for convenience. If set, baseLocation is
>>> always prepended to the given template name. For example, when
>>> baseLocation is set to "classpath:META-INF/templates/", a template by
>>> name, "foo.ftl", is resolved to
>>> "classpath:META-INF/templates/foo.ftl". If baseLocation property is
>>> null, template name must be given as fully qualified resource name
>>> (e.g, "classpath:META-INF/templates/foo.ftl").
>>
>> Thanks, merged!
>>
>> As of logging, I realize just now that we got policy discrepancies
>> there. What we have now is just FM2 heritage. There we have manually
>> predefined (and document) log categories; we don't use the class name
>> of the issuer class. But, FM2 wasn't modular, so it tells nothing
>> about that. So, what's the more important aspect of
>> SpringResourceTemplateLoader, for log filtering purposes? That it's in
>> the freemarker-spring module, or that it's template resolution
>> related? If the last, then after all your first commit was right to
>> use the _CoreLogs.TEMPLATE_RESOLVER log category. Or rather, the value
>> of _SpringLogs.TEMPLATE_RESOLVER should start with
>> _CoreLogs.TEMPLATE_RESOLVER + ".". But don't change anything for
>> now... we have no policy for these yet.
>>
>> Now, we can find out all kind of logging category policies, but a 3rd
>> party TemplateLoader certainly won't adhere to that (and BTW that
>> would require making log category names part of the published API),
>> and just does what pretty much all Java software nowadays does: use
>> the class name of the issuer as the log category. So you will miss the
>> log statements from the 3rd party TemplateLoader if you count on the
>> category starting with "org.apache.freemarker.templateresolver". So it
>> can't be counted on anyway. Thus even though FM2 categories are
>> superior in theory, I thin we should give that up and go with the
>> flow. It's also easier on contributors.
>>
>> What do you think?
>
> IMHO, it should be a lot easier for contributors to follow the most
> popular convention: "use FQCN of the issuer as the log category".
> It might be a little bit disadvantageous than FM2's well-organized
> category grouping, but using the most popular convention might be more
> helpful in maintenance and participation. Also, we can improve the
> modularity (e.g, package structure) as a compensation, I guess.
>
> Regards,
>
> Woonsan
>
>>
>> (As far as we stick to the old ways, instead of _SpringLogs.CORE I
>> would prefer _SpringLogs.ROOT, because CORE is somewhat reminiscent of
>> freemarker-core.)
>>
>>> Please review the PR, and please let me know if there's anything missed.
>>> I'll move on to FREEMARKER-55 very soon.
>>>
>>> Cheers,
>>>
>>> Woonsan
>>>
>>>> and the Web MVC part that builds on the first:
>>>> https://issues.apache.org/jira/browse/FREEMARKER-55
>>>>
>>>>
>>>> Friday, June 2, 2017, 4:56:38 PM, Woonsan Ko wrote:
>>>>
>>>>> On Fri, Jun 2, 2017 at 5:05 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>> Thursday, June 1, 2017, 5:09:07 PM, Woonsan Ko wrote:
>>>>>>
>>>>>>> On Wed, May 31, 2017 at 6:39 PM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>> Wednesday, May 31, 2017, 6:09:32 PM, Woonsan Ko wrote:
>>>>>>>>
>>>>>>>>> On Tue, May 30, 2017 at 11:38 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>>>> Tuesday, May 30, 2017, 5:02:43 PM, Woonsan Ko wrote:
>>>>>>>>> <snip>
>>>>>>>>>>>>>> Speaking of which, soon there will be one. Anyone is interested in FM3
>>>>>>>>>>>>>> Spring integration? The goal is that FM3's builder-based configuration
>>>>>>>>>>>>>> can be used seamlessly for creating the Spring beans. So certainly a
>>>>>>>>>>>>>> freemarker-spring module need to be added, which extends some classes
>>>>>>>>>>>>>> to implement FactoryBean interface and such. Also some configuration
>>>>>>>>>>>>>> defaults, like the TemplateLoader need to be different for sure, and
>>>>>>>>>>>>>> we need a TemplateLoader that uses Spring's Resource API. (I will
>>>>>>>>>>>>>> create an issue for it after I have polished the configuration API a
>>>>>>>>>>>>>> bit more.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, I am interested in FM3 spring integration.
>>>>>>>>>>>>> One question is, are we going to replace spring framework's default
>>>>>>>>>>>>> freemarker view support [1] by freemarker-spring in FM3?
>>>>>>>>>>>>
>>>>>>>>>>>> That would be the idea. And that will be the only possibility at the
>>>>>>>>>>>> beginning, as they only have FM2 support (and I guess contributing to
>>>>>>>>>>>> ASF/FM makes more sense than contributing to them).
>>>>>>>>>>>
>>>>>>>>>>> OK, got it.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Anyway, I'll happily help with this as soon as you create an issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Great! That will happen in a few days.
>>>>>>>>>>>
>>>>>>>>>>> I will try to list features of spring framework support for
>>>>>>>>>>> compatibility and other possible new features and improvements first.
>>>>>>>>>>> And, I'll try to discuss those items here soon.
>>>>>>>>>>
>>>>>>>>>> Sounds good.
>>>>>>>>>
>>>>>>>>> I've reviewed spring online documentation and tried to list all the
>>>>>>>>> features currently supported. We'll probably need to provide
>>>>>>>>> compatible solutions or alternatives for FM3. I added some notes on
>>>>>>>>> some items, too. Prioritization wasn't considered yet.
>>>>>>>>>
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> 1. Configuration support
>>>>>>>>>
>>>>>>>>> 1.1. Generic Configuration Factory bean support (that can be used for
>>>>>>>>> non web-apps)
>>>>>>>>> - FreeMarkerConfigurationFactoryBean
>>>>>>>>> - Note: perhaps the builder should be used internally inside the factory bean?
>>>>>>>>
>>>>>>>> The FactoryBean should extend Configuration.ExtenableBuilder. So it's
>>>>>>>> not even some internal stuff; ExtenableBuilder is public and was added
>>>>>>>> for things like this.
>>>>>>>>
>>>>>>>>> 1.2. Web MVC Configurer bean support
>>>>>>>>> - FreeMarkerConfigurer
>>>>>>>>
>>>>>>>> Ah that... whole thing. It's really confusing. It starts there that
>>>>>>>> it's hard to grasp for the user what a FreeMarkerConfigurer really is.
>>>>>>>> Because, we already have Configuration, and even a Spring-specific
>>>>>>>> class, FreeMarkerConfigurationFactoryBean that creates that. To
>>>>>>>> configure FreeMarker you need a Configuration, so a Configuration is
>>>>>>>> the real "FreeMarker configurer". But the "FreeMarkerConfigurer" name
>>>>>>>> suggests the same ("I configure FreeMarker"). So how is it different?
>>>>>>>> To make it more confusing, it's basically
>>>>>>>> FreeMarkerConfigurationFactoryBean (which is just a Configuration
>>>>>>>> Builder) with a few quirks:
>>>>>>>>
>>>>>>>> - It's technically not a FactoryBean. So instead of relying on Spring IoC
>>>>>>>> injection as usual, the dependent bean (FreeMarkerViewResolver
>>>>>>>> usually) has to call getConfiguration() on it.
>>>>>>>>
>>>>>>>> - getConfiguration() might returns a Configuration that wasn't built by
>>>>>>>> the FreeMarkerConfigurer! If you call setConfiguration(Configuration),
>>>>>>>> then that Configuration will be returned, and things you set on
>>>>>>>> FreeMarkerConfigurer (which is a Configuration Builder) doesn't
>>>>>>>> mater. Anyway, you would (or just I would?) think that if you want
>>>>>>>> the Web View stuff to use a specific Configuration, then you just inject
>>>>>>>> that Configuration bean into FreeMarkerViewResolver. But no, because
>>>>>>>> FreeMarkerViewResolver needs a FreeMarkerConfigurer. In fact,
>>>>>>>> FreeMarkerViewResolver doesn't need that directly. Instead, it just
>>>>>>>> specifies a class, FreeMarkerView, which in turn "manually" looks up
>>>>>>>> the FreeMarkerConfigurer bean with BeanFactoryUtils.
>>>>>>>>
>>>>>>>> - It provides a TaglibFactory object as well. I have to give that to
>>>>>>>> it, as that's at least something that Configuration doesn't do. But
>>>>>>>> if that will be the only obstacle of getting rid of
>>>>>>>> FreeMarkerConfigurer, then we stuff that into the Configuration,
>>>>>>>> like as a custom attribute (custom setting, if I have renamed it as
>>>>>>>> discussed), and as a real JavaBean property in our ExtenableBuilder
>>>>>>>> subclass.
>>>>>>>>
>>>>>>>> BTW Velocity support have the same hard to follow logic. Maybe it's
>>>>>>>> necessary, I don't know. Still, I wonder if we can make it more
>>>>>>>> elegant and less confusing for users. (Is it nicer with Thymeleaf for
>>>>>>>> example?) What I'm hoping for is that we can just use a Configuration
>>>>>>>> bean instead, and FreeMarkerView looks that up. The tricky part is how
>>>>>>>> to differentiate that bean from the other Configuration beans. The
>>>>>>>> natural solution is using a "web" qualifier, which is easy to follow
>>>>>>>> for the user as well (no magic, it's obvious how it works). But some
>>>>>>>> may feel it's not very stream lined (because I believe we can't
>>>>>>>> transparently make a bean qualified, so the user has to add it to its
>>>>>>>> configuration). So another possibility is subclassing Configuration,
>>>>>>>> so then we first look for a WebConfiguration (and then of course we
>>>>>>>> will also need a FreeMarkerWebConfigurationFactoryBean - note the
>>>>>>>> "Web" in it), and only if that's not found we look for "web" qualified
>>>>>>>> Configuration. But maybe all this is too different from Spring
>>>>>>>> tradition... I'm just thinking aloud.
>>>>>>>
>>>>>>> I will look into it further. But in general, the current
>>>>>>> FreeMarkerConfigurer based configuration looks confusing to me, and as
>>>>>>> you pointed out it's not even a FactoryBean and it's found out by the
>>>>>>> view resolver, etc. I feel like it could be neater. Let me investigate
>>>>>>> other things further and come back.
>>>>>>>
>>>>>>>>
>>>>>>>> BTW, I believe e-mail generation and other miscellaneous FreeMarker
>>>>>>>> applications (report generation, etc.) will be at least as important
>>>>>>>> as web pages nowadays.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>>
>>>>>>>>> and FreeMarkerViewResolver (basically extending UrlBasedViewResolver)
>>>>>>>>> - Note: the view resolver finds out the configurer bean by type by
>>>>>>>>> default.
>>>>>>>>
>>>>>>>> Well, if we stick to the approach with FreeMarkerConfigurer and all
>>>>>>>> that, the it's good enough. Otherwise see above.
>>>>>>>>
>>>>>>>>> Seems good enough for normal web application to me. Same
>>>>>>>>> pattern in the configurer by using builder internally?
>>>>>>>>
>>>>>>>> (The builders aren't meant to be internal, but it's the same as
>>>>>>>> earlier.)
>>>>>>>>
>>>>>>>>> 1.3. Annotation / XML Schema based configuration support
>>>>>>>>> (FreeMarkerConfigurer type bean)
>>>>>>>>> - Note: ViewResolverRegistry#freemarker() finds a bean by exact type
>>>>>>>>> of FreeMarkerConfigurer. alternative?
>>>>>>>>
>>>>>>>> What can we do about this at all? I mean, we can't add methods to this
>>>>>>>> class.
>>>>>>>
>>>>>>> Yeah. We may lose @EnableWebMvc feature since it seems tightly coupled
>>>>>>> with FreeMarkerConfigurer. Indeed, ViewResolverRegistry is created in
>>>>>>> a hard-coded way directly by WebMvcConfigurationSupport.
>>>>>>
>>>>>> Yet again, it might worth checking out what the Thymeleaf guys did, as
>>>>>> they focus heavily on Spring integration.
>>>>>
>>>>> OK. That sounds right. I'll take a look at how they do.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> (ref:
>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-config-view-resolvers)
>>>>>>>>>
>>>>>>>>> 1.4. XML Schema based configuration support
>>>>>>>>> - Note: alternative for this?
>>>>>>>>> <mvc:view-resolvers>
>>>>>>>>> <!-- SNIP -->
>>>>>>>>> <mvc:freemarker cache="false"/>
>>>>>>>>> </mvc:view-resolvers>
>>>>>>>>
>>>>>>>> XML config is low priority, I guess.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>>
>>>>>>>>> 2. View Resolution support
>>>>>>>>> - FreeMarkerViewResolver and FreeMarkerView
>>>>>>>>>
>>>>>>>>> 3. Tempplating Support
>>>>>>>>>
>>>>>>>>> 3.1. JSP Tag Libraries support
>>>>>>>>> - Spring / Spring form tag libraries and Spring binding macro support.
>>>>>>>>> - Note: It looks like spring macros (spring.ftl) are duplicate
>>>>>>>>> effort to the JSTL tag libraries, so I'm wondering if the macros were
>>>>>>>>> originally introduced before freemarker JSTL tag library support
>>>>>>>>> wasn't there or wasn't good enough. If so, perhaps can we stick to
>>>>>>>>> using JSTL tag libraries directly without having to rewrite/provide
>>>>>>>>> the macros?
>>>>>>>>> Or would it bring huge disruption in spring-mvc/freemarker community?
>>>>>>>>> Need to validate it more...
>>>>>>>>
>>>>>>>> So I guess that's where my domain knowledge ends. Which JSTL tags are
>>>>>>>> these? The Spring macros I have seen in SO questions and such call
>>>>>>>> Spring-specific functionality, not JSTL... or I just don't know what
>>>>>>>> JSTL can do. (Basic JSTL tags/functions are often duplicates core
>>>>>>>> FreeMarker functionality, like c:if, c:forEach, etc.) BTW, many JSTL
>>>>>>>> tags actually don't work with FreeMarker JSP support (I remember we
>>>>>>>> have a test case on @Ignore which demonstrates that). Pretty much only
>>>>>>>> traditional custom JSP tags do.
>>>>>>>
>>>>>>> I'm sorry for my confusion. I should have used (spring custom) "JSP
>>>>>>> tags", not "JSTL tags".
>>>>>>>
>>>>>>> Examples of "duplicate efforts" to me:
>>>>>>> - In Spring JSP Taglibs
>>>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html),
>>>>>>> it has 'message' tag.
>>>>>>> In spring.ftl, it also has 'message' macro and variants
>>>>>>> ('messageArgs', 'messageArgsText', ...).
>>>>>>> Perhaps there is a little to help with the macros, but developers
>>>>>>> can use jsp tag lib in ftl directly.
>>>>>>> - In Spring Form Taglibs
>>>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html),
>>>>>>> it has 'checkboxes' tag.
>>>>>>> spring.ftl defines macros too for the same functionality.
>>>>>>>
>>>>>>> So, I'm thinking if we can stick with JSP taglibs only, then we might
>>>>>>> not need to support those macros separately.
>>>>>>
>>>>>> I hope (but haven't checked) that Spring has a
>>>>>> view-technology-independent layer of this, and then the JSP custom
>>>>>> tags (and FreeMarker macros) are just adapting that to the conventions
>>>>>
>>>>> Ah, yes. That's something to check. Good point.
>>>>>
>>>>>> of the view technology (JSP, FTL). My concern with simply solving it
>>>>>> with yet another adapter layer (FTL to JSP) is that the logic of at
>>>>>> least some of these JSP tags is foreign from (modern) FTL. And the
>>>>>> same certainly goes for other view technologies as well (here again
>>>>>> it's might be a good idea to look what they did at Thymeleaf).
>>>>>
>>>>> OK.
>>>>>
>>>>>>
>>>>>> Let's take spring:message for example. Why's this a tag at all? It's
>>>>>> function, or even just a hash. If I had to expose such functionality
>>>>>> to FTL-s, it would look like `${messages.hello}` and
>>>>>> `${messages.hello(userName)}` and `${messages.hello(arg1, arg2,
>>>>>> argN)}`. This also means that you can pass a resolved message as an
>>>>>> argument to another macro/function: `<@foo messages.hello(userName)>`.
>>>>>> And what's up with the escaping parameters? Because normally HTML
>>>>>> autoescaping is ideally on, users has to do nothing to escape, and
>>>>>> they can write ${messages.thisIsAlreadyHTML?noEsc} otherwise. We
>>>>>> leverage core FTL functionality here, not need for any extra
>>>>>> `messages` parameter for that. (Not to mention that in general it's
>>>>>> not good that the user who inserts the message has to know if it's
>>>>>> already HTML or not. I mean they can't decide it there, because it's
>>>>>> already either HTML or plain text in the message data source. So,
>>>>>> `messages` should know that (the data source should store that
>>>>>> meta-information somehow). Then, `message.foo` returns an FTL String
>>>>>> if `foo` is plain text, and FTL HTML markup-output if `foo` is HTML
>>>>>> message, hence there's no need for ?noEsc in the last case, as
>>>>>> FreeMarker knows that it needs no further escaping.
>>>>>>
>>>>>> In the future we might run into other cases where we can't utilize FTL
>>>>>> features because the JSP obviously doesn't do that, and hence they
>>>>>> have duplicated it, or just don't have it.
>>>>>>
>>>>>> There are also cases of the opposite of it, i.e., where JSP can do
>>>>>> something that we can't, or at least it ugly and not idiomatic. Take
>>>>>> for example the `var` and `scope` attributes of the spring:messages
>>>>>> tag. Well, FTL has no out-parameters, nor scopes (even if the
>>>>>> FreemarkerServlet data-model emulates the last to an extent). But if
>>>>>> we solve this functionality with a function, as we should anyway (see
>>>>>> above), we return that thing, so we don't need an out-param. If
>>>>>> instead we just call spring:message with the JSP custom tag support of
>>>>>> FreeMarker, it won't magically transform it to a function.
>>>>>
>>>>> Good point! Sound better with extra ftl macros, not depending only on JSP tags.
>>>>>
>>>>>>
>>>>>>>>> 3.2. HTML escaping and XHTML compliance??
>>>>>>>>> - ref:
>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#views-form-macros-html-escaping,
>>>>>>>>>
>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>>>>>>>>
>>>>>>>>> - Note: If we stick with JSTL tags without any extra macros (3.1), I
>>>>>>>>> guess we won't need this special variable settings for escaping any
>>>>>>>>> more..
>>>>>>>>
>>>>>>>> So this is about how Spring (or you are saying, JSTL?) generated HTML
>>>>>>>> fragments use escaping internally.
>>>>>>>
>>>>>>> Sorry again, I should have said 'spring jsp tag libraries' instead.
>>>>>>> For example, the 'message' tag already has 'htmlEscape' attribute. So,
>>>>>>> when using the tag, ftl can use that attribute directly.
>>>>>>> By the way, 'htmlEscape' spring jsp tag wouldn't be used in .ftl,
>>>>>>> practically speaking as FM provides a better support.
>>>>>>
>>>>>> Yip.
>>>>>>
>>>>>>>>> 4. Testing support
>>>>>>>>> - ref:
>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#spring-mvc-test-server-htmlunit
>>>>>>>>> - Note: Make sure it works...
>>>>>>>>>
>>>>>>>>> 5. Micellaneous
>>>>>>>>>
>>>>>>>>> 5.1. Sending E-Mail support
>>>>>>>>> - ref:
>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mail-templates-example
>>>>>>>>> - Note: might be a low-hanging fruit by giving an example with
>>>>>>>>> freemarker instead...
>>>>>>>>
>>>>>>>> Yeah... especially if they will ever switch to freaking post-2.3.23
>>>>>>>> FreeMarker (they don't upgrade since we are incubating...), because
>>>>>>>> auto-escaping is missing from that example, and 2.3.24 does it much
>>>>>>>> better than 2.3.23.
>>>>>>>>
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> Personally, I wish to have the following in the future too:
>>>>>>>>>
>>>>>>>>> 6. More wishes
>>>>>>>>>
>>>>>>>>> 6.1. Generic FreeMarker Configuration Factory with JSTL support
>>>>>>>>> - I have an HMVC web application framework which uses spring
>>>>>>>>> framework as IoC, not MVC and Freemarker as view templating, but it
>>>>>>>>> needs to support JSTL tag libraries. So far I have dispatched requests
>>>>>>>>> to Freemarker servlet. I wish to configure a configuration factory and
>>>>>>>>> use the service somehow directly without having to use request
>>>>>>>>> dispatching any more...
>>>>>>>>
>>>>>>>> Not sure I follow, but isn't this using JSP support without
>>>>>>>> FreemarkerServlet? It's not well documented, but possible, like Spring
>>>>>>>> MVC does that too.
>>>>>>>
>>>>>>> Oh yeah?
>>>>>>
>>>>>> I'm not entirely sure... It think so as FreeMarkerConfigurer stores a
>>>>>> TaglibFactory.
>>>>>
>>>>> Yeah, I think I took a glance at that. Will look into it further.
>>>>>
>>>>> After studying how Thymeleaf guys do further, I can probably share better ideas.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Woonsan
>>>>>
>>>>>>
>>>>>>> That's good then. I'll try it later.
>>>>>>
>>>>>>> Thanks for all your input! I'll look into more detail and discuss further later.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Woonsan
>>>>>>>
>>>>>>>>
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> Folks, if you have experienced with spring + freemarker, please
>>>>>>>>> review/correct my understandings and chime in here.
>>>>>>>>> Also, it is probably a good time to speak up if you wish to have in
>>>>>>>>> the future. ;-)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I was a bit boggled down with the configuration API polishing, so I
>>>>>>>>>> haven't yet made the Jira issue. But I belive there's enough things to
>>>>>>>>>> do with the Spring integration before that becomes a problem. Things
>>>>>>>>>> will keep changing under it anyway. But that's just how refactoring
>>>>>>>>>> goes, and the same will happen again and again with freemarker-dom and
>>>>>>>>>> freemarker-servlet too.
>>>>>>>>>
>>>>>>>>> Yes, I think this spring framework support could be started in
>>>>>>>>> separate feature branch(es).
>>>>>>>>> I guess the most important ones from the list above are 1.1, 1.2, 2, and 3.1.
>>>>>>>>> Perhaps I can start working for those 4 items first in my github
>>>>>>>>> branch to merge it later.
>>>>>>>>> If there are other people who want to contribute to any of those, we
>>>>>>>>> can consider a shared feature branch instead...
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The goal would be not using the setSetting(String, String) API when
>>>>>>>>>> configuring under Spring, and work with beans and bean properties
>>>>>>>>>> cleanly. Ideally, only the builder classes need to be subclassed to
>>>>>>>>>> add some Spring annotations/interfaces and Spring-specific defaults.
>>>>>>>>>
>>>>>>>>> I see. And I saw your builder class is really extensible. That's great!
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> One thing that I will surely want to do in FM3 is allowing mixed
>>>>>>>>>> positional and named parameters in templates, like `f(1, 2, foo=3,
>>>>>>>>>> bar=4)` or `<@m 1, 2 foo=3 bar=4/>`. That's probably good to know when
>>>>>>>>>> it comes to calling Spring features from templates. (Of course this
>>>>>>>>>> will require replacing TemplateMethodModel and TemplateDirectiveModel
>>>>>>>>>> etc. with something better. Cleaning up the mess around the callable
>>>>>>>>>> objects is part of FM3 anyway.)
>>>>>>>>>
>>>>>>>>> Sounds good. I haven't found a good example of 'calling Spring
>>>>>>>>> features from templates' yet though. Maybe I'm missing something
>>>>>>>>> important...
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Woonsan
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Woonsan
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Woonsan
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/view.html#view-velocity-contextconfig
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Michael Brohl
>>>>>>>>>>>>>>> ecomify GmbH
>>>>>>>>>>>>>>> www.ecomify.de
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 17.05.17 um 14:29 schrieb Daniel Dekany:
>>>>>>>>>>>>>>>> Wednesday, May 17, 2017, 2:26:29 AM, Taher Alkhateeb wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yeah I closed it because it was a proposal for a PoC which you pretty much
>>>>>>>>>>>>>>>>> got done while I slacked :) Should I re-open? If yes then perhaps it should
>>>>>>>>>>>>>>>>> be renamed by removing the "PoC" part?
>>>>>>>>>>>>>>>> No, then it was right to close it after all. You can create an issue
>>>>>>>>>>>>>>>> for resolving the TODO-s and polishing the stuff it you think, though
>>>>>>>>>>>>>>>> honestly FM3 has tons and tons of non-Jiraed things to do... What
>>>>>>>>>>>>>>>> really counts if someone is interested in actually working on them.
>>>>>>>>>>>>>>>> (I'm not saying this to point at you or anyone. It's unpaid work etc.,
>>>>>>>>>>>>>>>> and if the project can't attract contributors, it's the fault of the
>>>>>>>>>>>>>>>> project and of its key persons, like me. The aspect that concerns me
>>>>>>>>>>>>>>>> is that if I do all the technical stuff, even if I was some kind of
>>>>>>>>>>>>>>>> superhuman one man army (and BTW I'm not) who can grind through
>>>>>>>>>>>>>>>> everything in time regardless, that will be a serious problem when it
>>>>>>>>>>>>>>>> comes to Apache incubation voting...)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, May 16, 2017 at 11:10 PM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I saw the Jira issue for migrating to Gradle was closed, but to be
>>>>>>>>>>>>>>>>>> clear it's far from done. Like, a major TODO is building the release
>>>>>>>>>>>>>>>>>> artifacts; the root project should do that (or should that be yet
>>>>>>>>>>>>>>>>>> another sub-project instead?).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The second most important deficiency is producing all the 3 Maven
>>>>>>>>>>>>>>>>>> artifacts for each published module (the usual artifact plus src and
>>>>>>>>>>>>>>>>>> javadoc). Currently we only produce one artifact per module, and it's
>>>>>>>>>>>>>>>>>> not even signed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BTW, I have factored out Manual generation into freemarker-manual
>>>>>>>>>>>>>>>>>> (non-published module). There's also a TODO there as its build doesn't
>>>>>>>>>>>>>>>>>> produce anything yet.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 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
Re: FM3 log categories (Was: Re: [FM3] Spring Framework Support)
Posted by Woonsan Ko <wo...@apache.org>.
On Tue, Jul 4, 2017 at 11:04 AM, Daniel Dekany <dd...@apache.org> wrote:
> Done, now we are just using
>
> private static final Logger LOG = LoggerFactory.getLogger(TheClassYouAreIn.class);
>
> everywhere.
Cool! Thanks!
Woonsan
>
>
> Monday, June 19, 2017, 4:04:20 PM, Woonsan Ko wrote:
>
>> On Mon, Jun 19, 2017 at 6:50 AM, Daniel Dekany <dd...@apache.org> wrote:
>>> Monday, June 19, 2017, 7:03:33 AM, Woonsan Ko wrote:
>>>
>>>> On Sat, Jun 3, 2017 at 9:50 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>>> I have created two issues for this. For the non-Web-MVC part:
>>>>> https://issues.apache.org/jira/browse/FREEMARKER-54
>>>>
>>>> I've opened new PR today.
>>>> In addition to the features described in the JIRA ticket, some minor were added:
>>>> - VersionEditor was added in core as Spring allows to set a Version
>>>> property value through a string instead by the PropertyEditor. This is
>>>> convenient in XML bean settings.
>>>> - baseLocation property was added (null by default) in
>>>> SpringResourceTemplateLoader for convenience. If set, baseLocation is
>>>> always prepended to the given template name. For example, when
>>>> baseLocation is set to "classpath:META-INF/templates/", a template by
>>>> name, "foo.ftl", is resolved to
>>>> "classpath:META-INF/templates/foo.ftl". If baseLocation property is
>>>> null, template name must be given as fully qualified resource name
>>>> (e.g, "classpath:META-INF/templates/foo.ftl").
>>>
>>> Thanks, merged!
>>>
>>> As of logging, I realize just now that we got policy discrepancies
>>> there. What we have now is just FM2 heritage. There we have manually
>>> predefined (and document) log categories; we don't use the class name
>>> of the issuer class. But, FM2 wasn't modular, so it tells nothing
>>> about that. So, what's the more important aspect of
>>> SpringResourceTemplateLoader, for log filtering purposes? That it's in
>>> the freemarker-spring module, or that it's template resolution
>>> related? If the last, then after all your first commit was right to
>>> use the _CoreLogs.TEMPLATE_RESOLVER log category. Or rather, the value
>>> of _SpringLogs.TEMPLATE_RESOLVER should start with
>>> _CoreLogs.TEMPLATE_RESOLVER + ".". But don't change anything for
>>> now... we have no policy for these yet.
>>>
>>> Now, we can find out all kind of logging category policies, but a 3rd
>>> party TemplateLoader certainly won't adhere to that (and BTW that
>>> would require making log category names part of the published API),
>>> and just does what pretty much all Java software nowadays does: use
>>> the class name of the issuer as the log category. So you will miss the
>>> log statements from the 3rd party TemplateLoader if you count on the
>>> category starting with "org.apache.freemarker.templateresolver". So it
>>> can't be counted on anyway. Thus even though FM2 categories are
>>> superior in theory, I thin we should give that up and go with the
>>> flow. It's also easier on contributors.
>>>
>>> What do you think?
>>
>> IMHO, it should be a lot easier for contributors to follow the most
>> popular convention: "use FQCN of the issuer as the log category".
>> It might be a little bit disadvantageous than FM2's well-organized
>> category grouping, but using the most popular convention might be more
>> helpful in maintenance and participation. Also, we can improve the
>> modularity (e.g, package structure) as a compensation, I guess.
>>
>> Regards,
>>
>> Woonsan
>>
>>>
>>> (As far as we stick to the old ways, instead of _SpringLogs.CORE I
>>> would prefer _SpringLogs.ROOT, because CORE is somewhat reminiscent of
>>> freemarker-core.)
>>>
>>>> Please review the PR, and please let me know if there's anything missed.
>>>> I'll move on to FREEMARKER-55 very soon.
>>>>
>>>> Cheers,
>>>>
>>>> Woonsan
>>>>
>>>>> and the Web MVC part that builds on the first:
>>>>> https://issues.apache.org/jira/browse/FREEMARKER-55
>>>>>
>>>>>
>>>>> Friday, June 2, 2017, 4:56:38 PM, Woonsan Ko wrote:
>>>>>
>>>>>> On Fri, Jun 2, 2017 at 5:05 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>> Thursday, June 1, 2017, 5:09:07 PM, Woonsan Ko wrote:
>>>>>>>
>>>>>>>> On Wed, May 31, 2017 at 6:39 PM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>>> Wednesday, May 31, 2017, 6:09:32 PM, Woonsan Ko wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, May 30, 2017 at 11:38 AM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>>>>> Tuesday, May 30, 2017, 5:02:43 PM, Woonsan Ko wrote:
>>>>>>>>>> <snip>
>>>>>>>>>>>>>>> Speaking of which, soon there will be one. Anyone is interested in FM3
>>>>>>>>>>>>>>> Spring integration? The goal is that FM3's builder-based configuration
>>>>>>>>>>>>>>> can be used seamlessly for creating the Spring beans. So certainly a
>>>>>>>>>>>>>>> freemarker-spring module need to be added, which extends some classes
>>>>>>>>>>>>>>> to implement FactoryBean interface and such. Also some configuration
>>>>>>>>>>>>>>> defaults, like the TemplateLoader need to be different for sure, and
>>>>>>>>>>>>>>> we need a TemplateLoader that uses Spring's Resource API. (I will
>>>>>>>>>>>>>>> create an issue for it after I have polished the configuration API a
>>>>>>>>>>>>>>> bit more.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, I am interested in FM3 spring integration.
>>>>>>>>>>>>>> One question is, are we going to replace spring framework's default
>>>>>>>>>>>>>> freemarker view support [1] by freemarker-spring in FM3?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That would be the idea. And that will be the only possibility at the
>>>>>>>>>>>>> beginning, as they only have FM2 support (and I guess contributing to
>>>>>>>>>>>>> ASF/FM makes more sense than contributing to them).
>>>>>>>>>>>>
>>>>>>>>>>>> OK, got it.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anyway, I'll happily help with this as soon as you create an issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Great! That will happen in a few days.
>>>>>>>>>>>>
>>>>>>>>>>>> I will try to list features of spring framework support for
>>>>>>>>>>>> compatibility and other possible new features and improvements first.
>>>>>>>>>>>> And, I'll try to discuss those items here soon.
>>>>>>>>>>>
>>>>>>>>>>> Sounds good.
>>>>>>>>>>
>>>>>>>>>> I've reviewed spring online documentation and tried to list all the
>>>>>>>>>> features currently supported. We'll probably need to provide
>>>>>>>>>> compatible solutions or alternatives for FM3. I added some notes on
>>>>>>>>>> some items, too. Prioritization wasn't considered yet.
>>>>>>>>>>
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> 1. Configuration support
>>>>>>>>>>
>>>>>>>>>> 1.1. Generic Configuration Factory bean support (that can be used for
>>>>>>>>>> non web-apps)
>>>>>>>>>> - FreeMarkerConfigurationFactoryBean
>>>>>>>>>> - Note: perhaps the builder should be used internally inside the factory bean?
>>>>>>>>>
>>>>>>>>> The FactoryBean should extend Configuration.ExtenableBuilder. So it's
>>>>>>>>> not even some internal stuff; ExtenableBuilder is public and was added
>>>>>>>>> for things like this.
>>>>>>>>>
>>>>>>>>>> 1.2. Web MVC Configurer bean support
>>>>>>>>>> - FreeMarkerConfigurer
>>>>>>>>>
>>>>>>>>> Ah that... whole thing. It's really confusing. It starts there that
>>>>>>>>> it's hard to grasp for the user what a FreeMarkerConfigurer really is.
>>>>>>>>> Because, we already have Configuration, and even a Spring-specific
>>>>>>>>> class, FreeMarkerConfigurationFactoryBean that creates that. To
>>>>>>>>> configure FreeMarker you need a Configuration, so a Configuration is
>>>>>>>>> the real "FreeMarker configurer". But the "FreeMarkerConfigurer" name
>>>>>>>>> suggests the same ("I configure FreeMarker"). So how is it different?
>>>>>>>>> To make it more confusing, it's basically
>>>>>>>>> FreeMarkerConfigurationFactoryBean (which is just a Configuration
>>>>>>>>> Builder) with a few quirks:
>>>>>>>>>
>>>>>>>>> - It's technically not a FactoryBean. So instead of relying on Spring IoC
>>>>>>>>> injection as usual, the dependent bean (FreeMarkerViewResolver
>>>>>>>>> usually) has to call getConfiguration() on it.
>>>>>>>>>
>>>>>>>>> - getConfiguration() might returns a Configuration that wasn't built by
>>>>>>>>> the FreeMarkerConfigurer! If you call setConfiguration(Configuration),
>>>>>>>>> then that Configuration will be returned, and things you set on
>>>>>>>>> FreeMarkerConfigurer (which is a Configuration Builder) doesn't
>>>>>>>>> mater. Anyway, you would (or just I would?) think that if you want
>>>>>>>>> the Web View stuff to use a specific Configuration, then you just inject
>>>>>>>>> that Configuration bean into FreeMarkerViewResolver. But no, because
>>>>>>>>> FreeMarkerViewResolver needs a FreeMarkerConfigurer. In fact,
>>>>>>>>> FreeMarkerViewResolver doesn't need that directly. Instead, it just
>>>>>>>>> specifies a class, FreeMarkerView, which in turn "manually" looks up
>>>>>>>>> the FreeMarkerConfigurer bean with BeanFactoryUtils.
>>>>>>>>>
>>>>>>>>> - It provides a TaglibFactory object as well. I have to give that to
>>>>>>>>> it, as that's at least something that Configuration doesn't do. But
>>>>>>>>> if that will be the only obstacle of getting rid of
>>>>>>>>> FreeMarkerConfigurer, then we stuff that into the Configuration,
>>>>>>>>> like as a custom attribute (custom setting, if I have renamed it as
>>>>>>>>> discussed), and as a real JavaBean property in our ExtenableBuilder
>>>>>>>>> subclass.
>>>>>>>>>
>>>>>>>>> BTW Velocity support have the same hard to follow logic. Maybe it's
>>>>>>>>> necessary, I don't know. Still, I wonder if we can make it more
>>>>>>>>> elegant and less confusing for users. (Is it nicer with Thymeleaf for
>>>>>>>>> example?) What I'm hoping for is that we can just use a Configuration
>>>>>>>>> bean instead, and FreeMarkerView looks that up. The tricky part is how
>>>>>>>>> to differentiate that bean from the other Configuration beans. The
>>>>>>>>> natural solution is using a "web" qualifier, which is easy to follow
>>>>>>>>> for the user as well (no magic, it's obvious how it works). But some
>>>>>>>>> may feel it's not very stream lined (because I believe we can't
>>>>>>>>> transparently make a bean qualified, so the user has to add it to its
>>>>>>>>> configuration). So another possibility is subclassing Configuration,
>>>>>>>>> so then we first look for a WebConfiguration (and then of course we
>>>>>>>>> will also need a FreeMarkerWebConfigurationFactoryBean - note the
>>>>>>>>> "Web" in it), and only if that's not found we look for "web" qualified
>>>>>>>>> Configuration. But maybe all this is too different from Spring
>>>>>>>>> tradition... I'm just thinking aloud.
>>>>>>>>
>>>>>>>> I will look into it further. But in general, the current
>>>>>>>> FreeMarkerConfigurer based configuration looks confusing to me, and as
>>>>>>>> you pointed out it's not even a FactoryBean and it's found out by the
>>>>>>>> view resolver, etc. I feel like it could be neater. Let me investigate
>>>>>>>> other things further and come back.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> BTW, I believe e-mail generation and other miscellaneous FreeMarker
>>>>>>>>> applications (report generation, etc.) will be at least as important
>>>>>>>>> as web pages nowadays.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> and FreeMarkerViewResolver (basically extending UrlBasedViewResolver)
>>>>>>>>>> - Note: the view resolver finds out the configurer bean by type by
>>>>>>>>>> default.
>>>>>>>>>
>>>>>>>>> Well, if we stick to the approach with FreeMarkerConfigurer and all
>>>>>>>>> that, the it's good enough. Otherwise see above.
>>>>>>>>>
>>>>>>>>>> Seems good enough for normal web application to me. Same
>>>>>>>>>> pattern in the configurer by using builder internally?
>>>>>>>>>
>>>>>>>>> (The builders aren't meant to be internal, but it's the same as
>>>>>>>>> earlier.)
>>>>>>>>>
>>>>>>>>>> 1.3. Annotation / XML Schema based configuration support
>>>>>>>>>> (FreeMarkerConfigurer type bean)
>>>>>>>>>> - Note: ViewResolverRegistry#freemarker() finds a bean by exact type
>>>>>>>>>> of FreeMarkerConfigurer. alternative?
>>>>>>>>>
>>>>>>>>> What can we do about this at all? I mean, we can't add methods to this
>>>>>>>>> class.
>>>>>>>>
>>>>>>>> Yeah. We may lose @EnableWebMvc feature since it seems tightly coupled
>>>>>>>> with FreeMarkerConfigurer. Indeed, ViewResolverRegistry is created in
>>>>>>>> a hard-coded way directly by WebMvcConfigurationSupport.
>>>>>>>
>>>>>>> Yet again, it might worth checking out what the Thymeleaf guys did, as
>>>>>>> they focus heavily on Spring integration.
>>>>>>
>>>>>> OK. That sounds right. I'll take a look at how they do.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> (ref:
>>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-config-view-resolvers)
>>>>>>>>>>
>>>>>>>>>> 1.4. XML Schema based configuration support
>>>>>>>>>> - Note: alternative for this?
>>>>>>>>>> <mvc:view-resolvers>
>>>>>>>>>> <!-- SNIP -->
>>>>>>>>>> <mvc:freemarker cache="false"/>
>>>>>>>>>> </mvc:view-resolvers>
>>>>>>>>>
>>>>>>>>> XML config is low priority, I guess.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2. View Resolution support
>>>>>>>>>> - FreeMarkerViewResolver and FreeMarkerView
>>>>>>>>>>
>>>>>>>>>> 3. Tempplating Support
>>>>>>>>>>
>>>>>>>>>> 3.1. JSP Tag Libraries support
>>>>>>>>>> - Spring / Spring form tag libraries and Spring binding macro support.
>>>>>>>>>> - Note: It looks like spring macros (spring.ftl) are duplicate
>>>>>>>>>> effort to the JSTL tag libraries, so I'm wondering if the macros were
>>>>>>>>>> originally introduced before freemarker JSTL tag library support
>>>>>>>>>> wasn't there or wasn't good enough. If so, perhaps can we stick to
>>>>>>>>>> using JSTL tag libraries directly without having to rewrite/provide
>>>>>>>>>> the macros?
>>>>>>>>>> Or would it bring huge disruption in spring-mvc/freemarker community?
>>>>>>>>>> Need to validate it more...
>>>>>>>>>
>>>>>>>>> So I guess that's where my domain knowledge ends. Which JSTL tags are
>>>>>>>>> these? The Spring macros I have seen in SO questions and such call
>>>>>>>>> Spring-specific functionality, not JSTL... or I just don't know what
>>>>>>>>> JSTL can do. (Basic JSTL tags/functions are often duplicates core
>>>>>>>>> FreeMarker functionality, like c:if, c:forEach, etc.) BTW, many JSTL
>>>>>>>>> tags actually don't work with FreeMarker JSP support (I remember we
>>>>>>>>> have a test case on @Ignore which demonstrates that). Pretty much only
>>>>>>>>> traditional custom JSP tags do.
>>>>>>>>
>>>>>>>> I'm sorry for my confusion. I should have used (spring custom) "JSP
>>>>>>>> tags", not "JSTL tags".
>>>>>>>>
>>>>>>>> Examples of "duplicate efforts" to me:
>>>>>>>> - In Spring JSP Taglibs
>>>>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html),
>>>>>>>> it has 'message' tag.
>>>>>>>> In spring.ftl, it also has 'message' macro and variants
>>>>>>>> ('messageArgs', 'messageArgsText', ...).
>>>>>>>> Perhaps there is a little to help with the macros, but developers
>>>>>>>> can use jsp tag lib in ftl directly.
>>>>>>>> - In Spring Form Taglibs
>>>>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html),
>>>>>>>> it has 'checkboxes' tag.
>>>>>>>> spring.ftl defines macros too for the same functionality.
>>>>>>>>
>>>>>>>> So, I'm thinking if we can stick with JSP taglibs only, then we might
>>>>>>>> not need to support those macros separately.
>>>>>>>
>>>>>>> I hope (but haven't checked) that Spring has a
>>>>>>> view-technology-independent layer of this, and then the JSP custom
>>>>>>> tags (and FreeMarker macros) are just adapting that to the conventions
>>>>>>
>>>>>> Ah, yes. That's something to check. Good point.
>>>>>>
>>>>>>> of the view technology (JSP, FTL). My concern with simply solving it
>>>>>>> with yet another adapter layer (FTL to JSP) is that the logic of at
>>>>>>> least some of these JSP tags is foreign from (modern) FTL. And the
>>>>>>> same certainly goes for other view technologies as well (here again
>>>>>>> it's might be a good idea to look what they did at Thymeleaf).
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>>>
>>>>>>> Let's take spring:message for example. Why's this a tag at all? It's
>>>>>>> function, or even just a hash. If I had to expose such functionality
>>>>>>> to FTL-s, it would look like `${messages.hello}` and
>>>>>>> `${messages.hello(userName)}` and `${messages.hello(arg1, arg2,
>>>>>>> argN)}`. This also means that you can pass a resolved message as an
>>>>>>> argument to another macro/function: `<@foo messages.hello(userName)>`.
>>>>>>> And what's up with the escaping parameters? Because normally HTML
>>>>>>> autoescaping is ideally on, users has to do nothing to escape, and
>>>>>>> they can write ${messages.thisIsAlreadyHTML?noEsc} otherwise. We
>>>>>>> leverage core FTL functionality here, not need for any extra
>>>>>>> `messages` parameter for that. (Not to mention that in general it's
>>>>>>> not good that the user who inserts the message has to know if it's
>>>>>>> already HTML or not. I mean they can't decide it there, because it's
>>>>>>> already either HTML or plain text in the message data source. So,
>>>>>>> `messages` should know that (the data source should store that
>>>>>>> meta-information somehow). Then, `message.foo` returns an FTL String
>>>>>>> if `foo` is plain text, and FTL HTML markup-output if `foo` is HTML
>>>>>>> message, hence there's no need for ?noEsc in the last case, as
>>>>>>> FreeMarker knows that it needs no further escaping.
>>>>>>>
>>>>>>> In the future we might run into other cases where we can't utilize FTL
>>>>>>> features because the JSP obviously doesn't do that, and hence they
>>>>>>> have duplicated it, or just don't have it.
>>>>>>>
>>>>>>> There are also cases of the opposite of it, i.e., where JSP can do
>>>>>>> something that we can't, or at least it ugly and not idiomatic. Take
>>>>>>> for example the `var` and `scope` attributes of the spring:messages
>>>>>>> tag. Well, FTL has no out-parameters, nor scopes (even if the
>>>>>>> FreemarkerServlet data-model emulates the last to an extent). But if
>>>>>>> we solve this functionality with a function, as we should anyway (see
>>>>>>> above), we return that thing, so we don't need an out-param. If
>>>>>>> instead we just call spring:message with the JSP custom tag support of
>>>>>>> FreeMarker, it won't magically transform it to a function.
>>>>>>
>>>>>> Good point! Sound better with extra ftl macros, not depending only on JSP tags.
>>>>>>
>>>>>>>
>>>>>>>>>> 3.2. HTML escaping and XHTML compliance??
>>>>>>>>>> - ref:
>>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#views-form-macros-html-escaping,
>>>>>>>>>>
>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>>>>>>>>>
>>>>>>>>>> - Note: If we stick with JSTL tags without any extra macros (3.1), I
>>>>>>>>>> guess we won't need this special variable settings for escaping any
>>>>>>>>>> more..
>>>>>>>>>
>>>>>>>>> So this is about how Spring (or you are saying, JSTL?) generated HTML
>>>>>>>>> fragments use escaping internally.
>>>>>>>>
>>>>>>>> Sorry again, I should have said 'spring jsp tag libraries' instead.
>>>>>>>> For example, the 'message' tag already has 'htmlEscape' attribute. So,
>>>>>>>> when using the tag, ftl can use that attribute directly.
>>>>>>>> By the way, 'htmlEscape' spring jsp tag wouldn't be used in .ftl,
>>>>>>>> practically speaking as FM provides a better support.
>>>>>>>
>>>>>>> Yip.
>>>>>>>
>>>>>>>>>> 4. Testing support
>>>>>>>>>> - ref:
>>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#spring-mvc-test-server-htmlunit
>>>>>>>>>> - Note: Make sure it works...
>>>>>>>>>>
>>>>>>>>>> 5. Micellaneous
>>>>>>>>>>
>>>>>>>>>> 5.1. Sending E-Mail support
>>>>>>>>>> - ref:
>>>>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mail-templates-example
>>>>>>>>>> - Note: might be a low-hanging fruit by giving an example with
>>>>>>>>>> freemarker instead...
>>>>>>>>>
>>>>>>>>> Yeah... especially if they will ever switch to freaking post-2.3.23
>>>>>>>>> FreeMarker (they don't upgrade since we are incubating...), because
>>>>>>>>> auto-escaping is missing from that example, and 2.3.24 does it much
>>>>>>>>> better than 2.3.23.
>>>>>>>>>
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> Personally, I wish to have the following in the future too:
>>>>>>>>>>
>>>>>>>>>> 6. More wishes
>>>>>>>>>>
>>>>>>>>>> 6.1. Generic FreeMarker Configuration Factory with JSTL support
>>>>>>>>>> - I have an HMVC web application framework which uses spring
>>>>>>>>>> framework as IoC, not MVC and Freemarker as view templating, but it
>>>>>>>>>> needs to support JSTL tag libraries. So far I have dispatched requests
>>>>>>>>>> to Freemarker servlet. I wish to configure a configuration factory and
>>>>>>>>>> use the service somehow directly without having to use request
>>>>>>>>>> dispatching any more...
>>>>>>>>>
>>>>>>>>> Not sure I follow, but isn't this using JSP support without
>>>>>>>>> FreemarkerServlet? It's not well documented, but possible, like Spring
>>>>>>>>> MVC does that too.
>>>>>>>>
>>>>>>>> Oh yeah?
>>>>>>>
>>>>>>> I'm not entirely sure... It think so as FreeMarkerConfigurer stores a
>>>>>>> TaglibFactory.
>>>>>>
>>>>>> Yeah, I think I took a glance at that. Will look into it further.
>>>>>>
>>>>>> After studying how Thymeleaf guys do further, I can probably share better ideas.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Woonsan
>>>>>>
>>>>>>>
>>>>>>>> That's good then. I'll try it later.
>>>>>>>
>>>>>>>> Thanks for all your input! I'll look into more detail and discuss further later.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Woonsan
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> Folks, if you have experienced with spring + freemarker, please
>>>>>>>>>> review/correct my understandings and chime in here.
>>>>>>>>>> Also, it is probably a good time to speak up if you wish to have in
>>>>>>>>>> the future. ;-)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I was a bit boggled down with the configuration API polishing, so I
>>>>>>>>>>> haven't yet made the Jira issue. But I belive there's enough things to
>>>>>>>>>>> do with the Spring integration before that becomes a problem. Things
>>>>>>>>>>> will keep changing under it anyway. But that's just how refactoring
>>>>>>>>>>> goes, and the same will happen again and again with freemarker-dom and
>>>>>>>>>>> freemarker-servlet too.
>>>>>>>>>>
>>>>>>>>>> Yes, I think this spring framework support could be started in
>>>>>>>>>> separate feature branch(es).
>>>>>>>>>> I guess the most important ones from the list above are 1.1, 1.2, 2, and 3.1.
>>>>>>>>>> Perhaps I can start working for those 4 items first in my github
>>>>>>>>>> branch to merge it later.
>>>>>>>>>> If there are other people who want to contribute to any of those, we
>>>>>>>>>> can consider a shared feature branch instead...
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The goal would be not using the setSetting(String, String) API when
>>>>>>>>>>> configuring under Spring, and work with beans and bean properties
>>>>>>>>>>> cleanly. Ideally, only the builder classes need to be subclassed to
>>>>>>>>>>> add some Spring annotations/interfaces and Spring-specific defaults.
>>>>>>>>>>
>>>>>>>>>> I see. And I saw your builder class is really extensible. That's great!
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> One thing that I will surely want to do in FM3 is allowing mixed
>>>>>>>>>>> positional and named parameters in templates, like `f(1, 2, foo=3,
>>>>>>>>>>> bar=4)` or `<@m 1, 2 foo=3 bar=4/>`. That's probably good to know when
>>>>>>>>>>> it comes to calling Spring features from templates. (Of course this
>>>>>>>>>>> will require replacing TemplateMethodModel and TemplateDirectiveModel
>>>>>>>>>>> etc. with something better. Cleaning up the mess around the callable
>>>>>>>>>>> objects is part of FM3 anyway.)
>>>>>>>>>>
>>>>>>>>>> Sounds good. I haven't found a good example of 'calling Spring
>>>>>>>>>> features from templates' yet though. Maybe I'm missing something
>>>>>>>>>> important...
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Woonsan
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Woonsan
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Woonsan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/view.html#view-velocity-contextconfig
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Michael Brohl
>>>>>>>>>>>>>>>> ecomify GmbH
>>>>>>>>>>>>>>>> www.ecomify.de
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Am 17.05.17 um 14:29 schrieb Daniel Dekany:
>>>>>>>>>>>>>>>>> Wednesday, May 17, 2017, 2:26:29 AM, Taher Alkhateeb wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yeah I closed it because it was a proposal for a PoC which you pretty much
>>>>>>>>>>>>>>>>>> got done while I slacked :) Should I re-open? If yes then perhaps it should
>>>>>>>>>>>>>>>>>> be renamed by removing the "PoC" part?
>>>>>>>>>>>>>>>>> No, then it was right to close it after all. You can create an issue
>>>>>>>>>>>>>>>>> for resolving the TODO-s and polishing the stuff it you think, though
>>>>>>>>>>>>>>>>> honestly FM3 has tons and tons of non-Jiraed things to do... What
>>>>>>>>>>>>>>>>> really counts if someone is interested in actually working on them.
>>>>>>>>>>>>>>>>> (I'm not saying this to point at you or anyone. It's unpaid work etc.,
>>>>>>>>>>>>>>>>> and if the project can't attract contributors, it's the fault of the
>>>>>>>>>>>>>>>>> project and of its key persons, like me. The aspect that concerns me
>>>>>>>>>>>>>>>>> is that if I do all the technical stuff, even if I was some kind of
>>>>>>>>>>>>>>>>> superhuman one man army (and BTW I'm not) who can grind through
>>>>>>>>>>>>>>>>> everything in time regardless, that will be a serious problem when it
>>>>>>>>>>>>>>>>> comes to Apache incubation voting...)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, May 16, 2017 at 11:10 PM, Daniel Dekany <dd...@apache.org> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I saw the Jira issue for migrating to Gradle was closed, but to be
>>>>>>>>>>>>>>>>>>> clear it's far from done. Like, a major TODO is building the release
>>>>>>>>>>>>>>>>>>> artifacts; the root project should do that (or should that be yet
>>>>>>>>>>>>>>>>>>> another sub-project instead?).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The second most important deficiency is producing all the 3 Maven
>>>>>>>>>>>>>>>>>>> artifacts for each published module (the usual artifact plus src and
>>>>>>>>>>>>>>>>>>> javadoc). Currently we only produce one artifact per module, and it's
>>>>>>>>>>>>>>>>>>> not even signed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW, I have factored out Manual generation into freemarker-manual
>>>>>>>>>>>>>>>>>>> (non-published module). There's also a TODO there as its build doesn't
>>>>>>>>>>>>>>>>>>> produce anything yet.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> 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
>