On Wed, Sep 13, 2017 at 5:50 AM, Daniel Dekany <[email protected]> wrote:
> Wednesday, September 13, 2017, 4:20:35 AM, Woonsan Ko wrote:
>
> [snip]
>> I've proposed a PR for tags defined in spring.tld for now:
>> https://github.com/apache/incubator-freemarker/pull/34
>> I'll continue to replace tags in form.tld.
>
> Thanks, looks good, I have merged it!
>
> One day (probably when you feel it's already polished) I will go
> through it thoroughly. For now I have more like skimmed through it. So
> tell me if I should look at something more closely, like you have some
> doubts there. Some random remarks:
>
> - AbstractSpringTemplateDirectiveModel and its subclasses probably
> shouldn't be public. (Also executeInternal probably should be
> protected.) Generally, we should avoid exposing things as published
> API-s, because they all become backward compatibility constraints.
> (It's major difficulty with libraries that thousands of projects
> depend on, as I have learned the hard way with FM2...)
>
> - final MessageSourceResolvable messageResolvable = (messageResolvableModel
> != null)
> ? (MessageSourceResolvable)
> objectWrapperAndUnwrapper.unwrap(messageResolvableModel) : null;
>
> You can have ClassCastException here instead of a TemplateException
> that explains the higher level problem. Certainly you should
> introduce and then use something like:
> CallableUtil.getAndUnwrapArgument(..., MessageSourceResolvable.class, ...)
>
> - Things similar to this:
>
> <#assign expression="T(java.lang.Math).max(12.34, 56.78)" />
> <div id="maxNumber">${spring.eval(expression)}</div>
>
> or this:
>
> <#assign pathInfo="http://freemarker.org/docs/index.html"; />
> <a href="${spring.url(pathInfo)}">Apache FreeMarker Manual</a>
>
> I think they are more readable (for most of us anyway) without the
> intermediate variable that's use only once. Like:
>
> <div id="maxNumber">${spring.eval("T(java.lang.Math).max(12.34,
> 56.78)")}</div>
I've proposed a new PR with the changes for all that you suggested
above. Good points! Thanks for the great suggestions!
And, I'd like to ask about this example:
<a class="userIdLink" href="${spring.url('/users/{userId}/',
userId=user.id?string)}">${user.id!}</a>
The reason why I had to use ?string built-in was that user.id returns
a TemplateNumberModel, while the function is expecting a string
argument.
But, if there's a way to convert a TemplateNumberModel to a string,
then I think the function might be more convenient without having to
use ?string.
Do you think if there's a way to improve this (allowing somethings
like TemplateNumberModel in this kind of string-expected values), or
?string is a good way? Or any other options?
Kind regards,
Woonsan
>
>> Thanks,
>>
>> Woonsan
>>
>>>
>>> Cheers,
>>>
>>> Woonsan
>>>
>>>>
>>>>> (ref:
>>>>> https://github.com/woonsan/spring-mvc-freemarker3-demo/blob/master/src/main/webapp/WEB-INF/views/useredit.ftl)
>>>>>
>>>>> Still need to add an example using 'message' named parameter.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Woonsan
>>>>>
>>>>>>
>>>>>>> look at `spring.message("foo")`, I think you would intuitively think
>>>>>>> that it prints the "foo" message. As of the others, I guess we don't
>>>>>>> need "text" as you can write ${spring.message("foo")!'default'}, nor
>>>>>>> do we need the xxxEscape parameters, as we have HTML auto-escaping and
>>>>>>> `spring.message("foo")?jsString`.
>>>>>>
>>>>>> Oh, cool! I didn't know we have ?jsString. Perfect.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Something that would be interesting if the spring.message function can
>>>>>>>>> somehow tell if a message is plain text or HTML. Like you can
>>>>>>>>> configure which messages are HTML on name patterns (or a content
>>>>>>>>> pattern, like all HTML values start with "<span>"). After all, without
>>>>>>>>> such a rule, how do the developers themselves know if a message should
>>>>>>>>> be HTML or plain text. Hopefully the have some exact policy for that.
>>>>>>>>> If spring.message knows that rule too, then for HTML messages it
>>>>>>>>> should return a TemplateMarkupOutputModel instead of a string, so it
>>>>>>>>> will be automatically non-escaped. Then people can just write
>>>>>>>>> ${spring.message("foo")} without worrying about `?noEsc`. And then we
>>>>>>>>> certainly don't need the directive "overload" either.
>>>>>>>>
>>>>>>>> As far as I know, MessageTag extends HtmlEscapingAwareTag which has
>>>>>>>> the following javadoc:
>>>>>>>>
>>>>>>>> * <p>Provides a "htmlEscape" property for explicitly specifying
>>>>>>>> whether to
>>>>>>>> * apply HTML escaping. If not set, a page-level default (e.g. from the
>>>>>>>> * HtmlEscapeTag) or an application-wide default (the
>>>>>>>> "defaultHtmlEscape"
>>>>>>>> * context-param in {@code web.xml}) is used.
>>>>>>>
>>>>>>> So then it seems we indeed need some spring library configuration
>>>>>>> parameter that associates an output format (as in
>>>>>>> http://freemarker.org/docs/dgui_misc_autoescaping.html) to each
>>>>>>> message, based on patterns. By default everything should be just plain
>>>>>>> text, to be on the safe side (i.e., auto-escaping will happen for
>>>>>>> them, because ${} does that). The equivalent of "defaultHtmlEscape"
>>>>>>> being on is that you assoicate "HTML" output format to all messages.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>>
>>>>>>> This also reinforces that, at least in the first iteration,
>>>>>>> spring.message should be function only, not a directive.
>>>>>>> `${spring.message("foo")}` isn't more verbose than
>>>>>>> `<@spring.message "foo" />` anyway.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>>
>>>>>>> BTW, I think it may worth having a special syntax for message
>>>>>>> insertion in the template language. For example,
>>>>>>> %{label.greet user, today} would be a syntactical sugar for
>>>>>>> ${someframewok.message('label.greet', user, today)}. But that's
>>>>>>> another topic.
>>>>>>
>>>>>> Sounds promising!
>>>>>>
>>>>>> Woonsan
>>>>>>
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Woonsan
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> By the way, I'm wondering what the best practices are in naming
>>>>>>>>>>> those
>>>>>>>>>>> models. Should it be better with 'form', 'spring_form',
>>>>>>>>>>> 'spring.form',
>>>>>>>>>>> or something else? Prefixing with something sounds safer to me.
>>>>>>>>>>
>>>>>>>>>> In the templates they should be accessible as <@spring.bind ...> and
>>>>>>>>>> such. In the case of the form tags, as it's in a separate namespace
>>>>>>>>>> in
>>>>>>>>>> JSP, maybe it should be <@form.input ...> etc. (Though I'm not 100%
>>>>>>>>>> sure if its practical the structure of the JSP taglibs so closely,
>>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> I meant: "if it's practical to follow the structure of the JSP taglibs
>>>>>>>>> so closely"
>>>>>>>>>
>>>>>>>>>> maybe we could just go with <@spring.input ...>. I don't know.)
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Woonsan
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html
>>>>>>>>>>> [2]
>>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Besides, just to be absolutely clear, I would merge your current
>>>>>>>>>>>>>> PR as
>>>>>>>>>>>>>> well, if it doesn't raise licensing issues, which is of course a
>>>>>>>>>>>>>> blocker.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, no worries. I was also under a concern about that and
>>>>>>>>>>>>> wanted to
>>>>>>>>>>>>> get feedbacks before doing too much. ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Woonsan
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Monday, August 7, 2017, 4:23:26 PM, Woonsan Ko wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Aug 6, 2017 at 6:14 AM, Daniel Dekany
>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>> The big problem is that spring.ftl is copyrighted by some of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> Spring authors (or the Spring project as a whole - it's not
>>>>>>>>>>>>>>>> clear). So
>>>>>>>>>>>>>>>> certainly we can't just copy it. It has to be reimplemented
>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>> looking at the source, or something absurd like that. Perhaps
>>>>>>>>>>>>>>>> the best
>>>>>>>>>>>>>>>> is to start out from the spring JSP taglib, as that's the most
>>>>>>>>>>>>>>>> widely
>>>>>>>>>>>>>>>> used templating solution (I assume), so certainly that's the
>>>>>>>>>>>>>>>> one where
>>>>>>>>>>>>>>>> all the features are exposed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wonder if using #import + FTL is the best way of adding
>>>>>>>>>>>>>>>> framework-level functionality that's used by a lot of people.
>>>>>>>>>>>>>>>> It's
>>>>>>>>>>>>>>>> surely an OK way, but it's not the highest performance way.
>>>>>>>>>>>>>>>> The other
>>>>>>>>>>>>>>>> way is using a shared variable (or some other kind of commonly
>>>>>>>>>>>>>>>> visible
>>>>>>>>>>>>>>>> variable) and implement the library in Java using
>>>>>>>>>>>>>>>> TemplateDirectiveModel-s and TemplateFunctionModel-s. It's less
>>>>>>>>>>>>>>>> convenient than doing it in FTL, but it has to be done once,
>>>>>>>>>>>>>>>> while you
>>>>>>>>>>>>>>>> save some resources everywhere where it's used. Though as most
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> these macros/functions are quite simple, I don't think the
>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>> difference matters much. But, it also avoids the legal issue
>>>>>>>>>>>>>>>> above. I
>>>>>>>>>>>>>>>> mean, many of these function/macros are so trivial, that it's
>>>>>>>>>>>>>>>> hard to
>>>>>>>>>>>>>>>> implement them on a different way in FTL than as it is in the
>>>>>>>>>>>>>>>> Spring
>>>>>>>>>>>>>>>> source code, but if you implement them in Java, then it's much
>>>>>>>>>>>>>>>> harder
>>>>>>>>>>>>>>>> to accuse anyone with stealing. (A minor annoyance right now
>>>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>>> that part of the FreeMarker API is not yet settled; see
>>>>>>>>>>>>>>>> FREEMARKER-63,
>>>>>>>>>>>>>>>> FREEMARKER-64, FREEMARKER-65. But hopefully it will be in a
>>>>>>>>>>>>>>>> good
>>>>>>>>>>>>>>>> enough shape soon. And see other thread; input is welcome!)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As of template aliases, at the first glance that's fine. Note
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> there's MultiTemplateLoader which does something similar, but
>>>>>>>>>>>>>>>> I assume
>>>>>>>>>>>>>>>> it would be less neat (and/or slower) to do this with that.
>>>>>>>>>>>>>>>> (But if
>>>>>>>>>>>>>>>> the spring functionality won't be #import-ed after all (as
>>>>>>>>>>>>>>>> above), the
>>>>>>>>>>>>>>>> whole thing can become unnecessary...)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you very much for sharing your insights. Greatly helpful
>>>>>>>>>>>>>>> advice.
>>>>>>>>>>>>>>> I agree that it might be better with template model(s) rather
>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>> library FTL in various aspects.
>>>>>>>>>>>>>>> Let me try with that approach again and let you know soon with
>>>>>>>>>>>>>>> a new PR.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank again,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Woonsan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sunday, August 6, 2017, 7:22:00 AM, ASF GitHub Bot (JIRA)
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115649#comment-16115649
>>>>>>>>>>>>>>>>> ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ASF GitHub Bot commented on FREEMARKER-55:
>>>>>>>>>>>>>>>>> ------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> GitHub user woonsan opened a pull request:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/apache/incubator-freemarker/pull/31
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FREEMARKER-55: spring.ftl marco lib support
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Support <#import "/spring.ftl" as spring> like Spring
>>>>>>>>>>>>>>>>> Framework does.
>>>>>>>>>>>>>>>>> - By default, the system lib from /spring.ftl is read
>>>>>>>>>>>>>>>>> from the
>>>>>>>>>>>>>>>>> specific classpath, not from app's template path.
>>>>>>>>>>>>>>>>> The system template aliases map can be customized
>>>>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>>>> SpringResourceTemplateLoader.systemTemplateAliases property.
>>>>>>>>>>>>>>>>> - The same macros and functions are defined in
>>>>>>>>>>>>>>>>> /spring.ftl as
>>>>>>>>>>>>>>>>> Spring Framework's, with syntax changes to comply with FM3.
>>>>>>>>>>>>>>>>> - Note: As the system template lib support is handled by
>>>>>>>>>>>>>>>>> SpringTemplateLoader in this PR, it means developers should
>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>> use SpringTemplateLoader directly or indirectly in order to
>>>>>>>>>>>>>>>>> use the
>>>>>>>>>>>>>>>>> system macro library. Please review this decision.
>>>>>>>>>>>>>>>>> - TODOs: review/test/refine each macro and functions in
>>>>>>>>>>>>>>>>> spring.ftl.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You can merge this pull request into a Git repository by
>>>>>>>>>>>>>>>>> running:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> $ git pull
>>>>>>>>>>>>>>>>> https://github.com/woonsan/incubator-freemarker
>>>>>>>>>>>>>>>>> feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Alternatively you can review and apply these changes as the
>>>>>>>>>>>>>>>>> patch at:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/apache/incubator-freemarker/pull/31.patch
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To close this pull request, make a commit to your
>>>>>>>>>>>>>>>>> master/trunk branch
>>>>>>>>>>>>>>>>> with (at least) the following in the commit message:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This closes #31
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>>>>> commit 8e0f33c419d982279d7fb22a9dfdc66f47abaf2c
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-07-14T15:27:17Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FREEMARKER-55: Renaming Freemarker to FreeMarker
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit ec8d687d4ce2c0e1bb3e3ca073b139eacc198527
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-07-14T15:53:51Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merge branch '3' into feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit e7cb6f7cfc241689c85527971bf6e1ea7ced9127
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-07-14T17:57:29Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merge branch '3' into feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit c6eb09de91e57035c1e0e3c4d3490b3b96622bab
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-07-16T18:24:55Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merge branch '3' into feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit 870209fa8e0acd0bb3186053dfd549b5c758e37d
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-07-18T00:38:03Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merge branch '3' into feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit 4481406a2f4eeb30d6d044a4ac158efab7ba7a7b
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-08-06T01:28:54Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merge branch '3' into feature/FREEMARKER-55
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> commit fcd9e672ec515e3042bc5efd229b7d12c23e7d88
>>>>>>>>>>>>>>>>> Author: Woonsan Ko <[email protected]>
>>>>>>>>>>>>>>>>> Date: 2017-08-06T05:09:12Z
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FREEMARKER-55: system template lib for spring app:
>>>>>>>>>>>>>>>>> spring.ftl.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FM3 freemarker-spring module, Web MVC support
>>>>>>>>>>>>>>>>>> ---------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Key: FREEMARKER-55
>>>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/FREEMARKER-55
>>>>>>>>>>>>>>>>>> Project: Apache Freemarker
>>>>>>>>>>>>>>>>>> Issue Type: Task
>>>>>>>>>>>>>>>>>> Affects Versions: 3.0.0
>>>>>>>>>>>>>>>>>> Reporter: Daniel Dekany
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Add Spring "Web MVC framework" functionality to
>>>>>>>>>>>>>>>>>> freemarker-spring.
>>>>>>>>>>>>>>>>>> This can be complex task (and the issue possibly has to be
>>>>>>>>>>>>>>>>>> subdivided), as it involves things like:
>>>>>>>>>>>>>>>>>> * Some aspects of the FreeMarker 2 integration (developed by
>>>>>>>>>>>>>>>>>> the Spring developers) are quite confusing
>>>>>>>>>>>>>>>>>> ({{FreemarerConfigurer}}, etc.), and we are looking into if
>>>>>>>>>>>>>>>>>> it needs to be like that.
>>>>>>>>>>>>>>>>>> * See if we can support {{@EnableWebMvc}} (note that
>>>>>>>>>>>>>>>>>> FreeMarker 2 support is hard coded into
>>>>>>>>>>>>>>>>>> {{ViewResolverRegistry}}, which we can't modify)
>>>>>>>>>>>>>>>>>> * Creating custom directives/methods to expose Spring
>>>>>>>>>>>>>>>>>> features like the Spring JSP Tag Library does (but in a way
>>>>>>>>>>>>>>>>>> that firs FreeMarker better)
>>>>>>>>>>>>>>>>>> * Expose JSP custom tag support from the
>>>>>>>>>>>>>>>>>> {{freemarker-servlet}} module.
>>>>>>>>>>>>>>>>>> Depends on: FREEMARKER-54
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> This message was sent by Atlassian JIRA
>>>>>>>>>>>>>>>>> (v6.4.14#64029)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Daniel Dekany
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Daniel Dekany
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Daniel Dekany
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks,
>>>>>>>>> Daniel Dekany
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> Daniel Dekany
>>>>>>>
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>
>
> --
> Thanks,
> Daniel Dekany
>
