On Tue, May 30, 2017 at 11:38 AM, Daniel Dekany <ddek...@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?
1.2. Web MVC Configurer bean support
- FreeMarkerConfigurer and FreeMarkerViewResolver (basically
extending UrlBasedViewResolver)
- Note: the view resolver finds out the configurer bean by type by
default. Seems good enough for normal web application to me. Same
pattern in the configurer by using builder internally?
1.3. Annotation / XML Schema based configuration support
(FreeMarkerConfigurer type bean)
- Note: ViewResolverRegistry#freemarker() finds a bean by exact type
of FreeMarkerConfigurer. alternative?
(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>
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...
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..
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...
-----
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...
-----
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 <ddek...@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
>
