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. > >> (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. > >> 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. > >> 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? 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 >
