Re: weird macro params issue

Thursday, May 22, 2008, 1:40:18 PM, Felix Gnass wrote:

> Daniel Dekany wrote:
>> Thursday, May 22, 2008, 11:52:06 AM, Attila Szegedi wrote:
>>
>>   
>>> On 2008.05.22., at 1:14, Jonathan Revusky wrote:
>>>
>>>     
>>>> It simply uses the value of y as defined at that point as a constant
>>>> default value. It doesn't change if y changes. I wasn't 100% sure of
>>>> this, which shows how deep my knowledge of python is, but the above
>>>> semantics didn't surprise me at all. I have the sense (illusory) that
>>>> I understand the mindset behind Python. (Kind of reminds me of those
>>>> Christian fundamentalist bumper stickers you see in the states "What
>>>> would Jesus do?" except "What would Guido do?")
>>>>       
>>> Yep, you can develop that.
>>>
>>>     
>>>> BUt seriously, this really has me thinking that, unless we're in a
>>>> competition to have the funkiest dynamic language around (perhaps kind
>>>> of like trying to be more catholic than the pope) we should take a
>>>> step back from this and just think about how desirable it is really to
>>>> have these semantics. I would tend to think that the Guido way, how it
>>>> works in python, is the best, most straightforward option, and we
>>>> should go that way. There is the matter of this having worked (or kind
>>>> of) in 2.3. But I can't believe we would break many templates by
>>>> disallowing it. It's probably fairly rare that people rely on this.
>>>>       
>>> I don't know. I guess I'm okay with that too, it's just that I figured
>>> out that this is something that can be make to work fairly easily, and
>>> all it does is adds to the expressive power of the language in a  
>>> nonintrusive manner (if you don't use it, you don't see it). If,  
>>> however others consider this to be too "funky", well, let's go for the
>>> fail-always... I wonder what's Daniel's opinion...
>>>     
>>
>> I can't tell a use-case for this right now...
>>
>>   
>
> Hello,
>
> our form library contains a use-case that IMHO illustrates the power of
> this feature. It contains macros to  render various HTML form elements
> and can be used as replacement for the spring.ftl library that comes 
> with the Spring Web-MVC framework. The original Spring macros are quite
> inconvenient because they don't leverage any of FreeMarker's advanced 
> language features. Instead they try to be 100% compatible with the 
> Velocity macros (which are also provided by Spring).
>
> All form-field macros automatically render an "id" attribute so that you
> can easily include a <label for="..."> tag for them.
>
> <@form.label for="foo" />
> <@form.input type="text" field="foo" />
>
> The id defaults to the field-name which makes sense in 99% percent of 
> all cases. Nevertheless you are sometimes forced to assign a different

Ugh... I'm getting old or what. Because, yeah, obviously, that's a
use-case for this, and it's not even a rare thing.

> id because the document already contains another element with the same
> identifier (quite likely when there multiple forms on one page). In this
> case you can write:
>
> <@form.label for="myFoo" field="foo" />
> <@form.input type="text" field="foo" id="myFoo" />
>
> Another use-case is the option-tag where the label defaults to the 
> value. This allows you to write
> <@form.option "foo" /> as well as <@form.option "foo" "42" />.
>
> All the examples above could also be implemented when there was support
> for _optional_ parameters _without_ a default value or a "null" default.

One of the important design mistakes of FTL is that it doesn't support
true optional parameters (but starting from 2.4 it will at least
support null as the default parameter value). Still, I don't think
this is a case that should be solved with them.

> I'm thinking of something like <#macro label for field=null> or better:
> <#macro label for field!> due to FreeMarker's null-unawareness.
>
> In Python you can use the "None" object as default so there's no need 
> for constructs like foo(x, y=x).
>
> Currently the only possibility in FreeMarker is to abuse empty strings
> and use the ?has_content built-in, which is quite an ugly hack, as it 
> means that users can't pass empty strings to the macro (well they could
> but it would make no sense) because this would be equivalent to simply
> not specifying the parameter at all.
>
> I think these are two valid use-cases and it would be really nice if 
> FreeMarker would officially support this undocumented language feature.

Yes, feature request accepted as far as I'm concerned...

> -Felix

-- 
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/