Re: weird macro params issue

On Thu, May 22, 2008 at 1:40 PM, Felix Gnass <[email protected]> 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:

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

A few years back, there were various discussions in some of these
communities about whether it was worth supporting freemarker (What's
that?) I think the discussion is now soon going to shift over to the
question of whether it is worthwhile to continue to  support Velocity.
THough I guess Struts 2 will continue to support it as a kind of
"sacred cow".

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


FreeMarker 2.4 introduces a null type, so you could write:

<#macro foo x y=null>
  <#set y = y!x>

</#macro>


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

Or you could use a special value as a pseudo-null:


<#macro foo x y="UNDEFINED">
  <#if y=="UNDEFINED><#local y = x></#if>
....

>
> I think these are two valid use-cases and it would be really nice if
> FreeMarker would officially support this undocumented language feature.

It's a tough call because in 2.4 we do have null and it seems simpler
there just to do it basically the Python way. Of course, 2.3 will be
in use for a long time so..... I really don't know...

JR

>
> -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/
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

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