On Tue, Jul 4, 2017 at 11:04 AM, Daniel Dekany <[email protected]> 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 <[email protected]> wrote: >>> Monday, June 19, 2017, 7:03:33 AM, Woonsan Ko wrote: >>> >>>> On Sat, Jun 3, 2017 at 9:50 AM, Daniel Dekany <[email protected]> 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 <[email protected]> wrote: >>>>>>> Thursday, June 1, 2017, 5:09:07 PM, Woonsan Ko wrote: >>>>>>> >>>>>>>> On Wed, May 31, 2017 at 6:39 PM, Daniel Dekany <[email protected]> >>>>>>>> wrote: >>>>>>>>> Wednesday, May 31, 2017, 6:09:32 PM, Woonsan Ko wrote: >>>>>>>>> >>>>>>>>>> On Tue, May 30, 2017 at 11:38 AM, Daniel Dekany <[email protected]> >>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> <[email protected]> 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 >
