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 <[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
