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 <[email protected]> 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
