Saturday, August 26, 2017, 10:17:55 AM, Daniel Dekany wrote:
> Saturday, August 26, 2017, 7:27:03 AM, Woonsan Ko wrote:
>
>> Hi Daniel,
>>
>> I've tried to write a directive to replace the spring:bind tag
>> library. But I get "IllegalStateException: Not executing macro body"
>> when invoking Environment#setLocalVariable(...).
>> <@spring.bind> is supposed to set a variable called 'status'. Could
>> you give me a hint on how to add a variable in a directive?
>
> The local variables are those that you could set with #local in a
> template, so setLocalVariable will only work if the directive is
> called from inside #macro or #function. I guess what you meant is
> setting a nested content variable
Actually, it's called a nested content *parameter*. It's like if the
directive passes an argument to the nested content, so on the caller
side it's like declaring a parameter name.
> (aka. loop variable), in but then
> the call syntax had to be `<@spring.bind "user.name"; status>...`.
> That is, the name of the target variable can't be specified by the
> directive, it's controlled by the caller. That's perhaps too
> inconvenient for this purpose though, as everyone just wants to call it
> "status". So certainly you should set a namespace-scoped (like
> #assign) or global (like #global) variable with setVariable or
> setGlobalVariable respectively. Of course, before setting them, they
> have to be read to store the old value, and then restored at the end.
Though the only pure solution is with nested content parameters...
Because for example here, `status` will be the local variable, as it
shadows the `status` set in a higher scope:
<#macro foo>
<#local status = 'blah'>
<@spring.bind "user.name">
${status.value} <#-- Means 'blah'.value, won't work -->
With nested content parameter it's also more obvious what's going on,
and if you chose a shorter name it's not that verbose either:
<@spring.bind "user.name"; s>
${s.value} <#-- Means 'blah'.value, won't work -->
That's the FreeMarkerish approach anyway. Setting variables from
inside a directive implementation, without the calling seeing that, is
generally a bad practice. If `status` were inside the `spring` hash,
then it would be fine, but that's certainly too verbose:
`${spring.status.value}`.
>> Thanks in advance,
>>
>> Woonsan
>>
>>
>> On Thu, Aug 24, 2017 at 6:19 AM, Woonsan Ko wrote:
>>> On Mon, Aug 21, 2017 at 12:19 AM, Daniel Dekany wrote:
Monday, August 7, 2017, 9:18:36 PM, Woonsan Ko wrote:
> On Mon, Aug 7, 2017 at 11:03 AM, Daniel Dekany wrote:
>> If you are going to implement these directly as
>> TemplateDirectiveModel-s and TemplateFunctionModel-s, then you better
>> wait until I merge at least the FREEMARKER-63 PR... probably also
>> FREEMARKER-64. I will try to do that tonight. At least 63.
>
> OK, I'll watch and wait for that. :-)
FREEMARKER-63, 64 and 65 has been committed. Try to use CallableUtils
for argument validation and other exception creation. See
AssertFailsDirective as an example. Of course, ideas for improving
CallableUtils are highly welcome.
BTW, certainly there are several TemplateFunctionModel and
TemplateDirectiveModel implementations that could but don't yet use
CallableUtils for argument validation. If you spot some, you may go
ahead and improve them.
>>>
>>> Thank you so much! I've briefly browsed the PRs linked from the JIRA
>>> tickets, and it is really great! Really easy to extend it with
>>> TemplateCallableModel. Very simple but really powerful! I also saw
>>> IncludePage directive (as named "include_page") in
>>> freemarker-servlet; it looks really straightforward.
>>> I'll try to write equivalent directives or functions from spring JSP
>>> Tag Library [1] and spring-form JSP Tag Library [2].
>>> 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.
>>>
>>> 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
>>> wrote:
The big problem is that spring.ftl is copyrighted by some of the
