Re: weird macro params issue

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-cases 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 
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. 
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.

-Felix

-------------------------------------------------------------------------
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/