That's a good point, library customization is an important application
of "dynamic" macro definition and #include. But then, static
languages, like Java, can do that too, though they had to introduce
their own specialized mechanism for that purpose. So if FreeMarker 3
will be more static (and I hope that we can get rid of #include as
part of that), it will be possible too... somehow. We will see.
Wednesday, January 20, 2016, 9:45:35 PM, David E Jones wrote:
> It is useful to allow macro overrides, ie replace the macro and don’t throw an exception.
>
> As a specific use case: in Moqui for screen/form rendering
> (translating XML screen/form/etc definitions to HTML, data XML, CSV,
> XSL-FO, etc) there are macro libraries with around 65 macros for
> each output type. While it is nice to have default macros, and
> necessary for things to run OOTB, many users want to (for example)
> produce different HTML. With the macro replace using the same name
> this is easy, just: tell the rendering code to use a different macro
> library, include the default macro library in your macro library,
> define macros to override default ones, and off you go.
>
> -David
>
>
>> On 20 Jan 2016, at 10:16, Daniel Dekany <ddekany@freemail.hu> wrote:
>>
>> The problem with detecting that is that macros aren't really
>> statically declared. Macros are created as the template runs the
>> #macro directive. It's quite analogous to #assign in that regard, and
>> of course you can assign to the same variable twice. However, unlike
>> with #assign, there's trick, which let's you call a macro that is
>> defined later. FreeMarker simply pre-assigns one of the definitions to
>> a variable, which will be simply overwritten by the later #macro
>> calls.
>>
>> I'm not saying I'm big fan of the mechanism though. In FreeMarker 3, I
>> think it would be good to make things more static, such as #macro
>> would be completely parse-time. (If someone wants to call a macro
>> "dynamically", that should be possible, but an some different way.)
>> Among others because of tooling support. Many users want to analyze
>> templates, but the more dynamic the language, the less reliable the
>> results are.
>>
>>
>> Wednesday, January 20, 2016, 2:26:24 PM, Albert Kam wrote:
>>
>>> Hi guys !
>>>
>>> My need is just to detect unintended macro name duplicates resulting from
>>> multiple template merges.
>>>
>>> I tried :
>>>
>>> <@test />
>>>
>>> <#macro test>
>>> Testing 1
>>> </#macro>
>>>
>>> <#macro test>
>>> Testing 2
>>> </#macro>
>>>
>>> And it prints out Test 2.
>>>
>>> What i expect is to throw exception upon finding dupes, or maybe in the
>>> template itself i can check the amount of macro variables ?
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
>
--
Thanks,
Daniel Dekany
|