From: Lane S. <la...@op...> - 2003-03-07 19:08:31
|
Hi Dario, I have done some work with macros. The design, which is robust, requires you to include macros on a per file basis, not a per request basis. This was explained to me by bg as following a common pattern and I have come to adopt it but like you can imagine some alternatives. To include the "standard" WM macro library, as in std.h, look at the docs and macros in the distribution dir macros/. This model includes all macros in all subdirectories and each macro in the varying subDirs get tested. I liked a lot your example below which shows the power of #setblock as macro {..}. I had never thought of passing a block like this into a macro and using $body. Very cool. -Lane Dario Liberman wrote: >RE: Passing a block to a macro?Hello all, > >Thanks again Keats, and also to Eric! :-) > >I tryed to pass a block to a macro and works fine. > >for example: > >#macro loop($body,$times) #begin > #count $i from 1 to $times { > $body > } >#end > >#set $piramid="" >#setblock as macro $blk { > #set $piramid="$piramid@" > $piramid<BR> >} > ><CENTER> >#loop($blk,7) ></CENTER> > >produces what expected: > @ > @@ >@@@ >... > > >And althought it is true that a directive can be made writing java code, >what am I saying is that defining macros with body is much easier. So >wrinting only one directive, say #macrowithbody or #nestedmacro we have a >kind of directive-alike macro creation directive. > >So I would have a special variable inside the macro definition (that can be >configured, like the counter variable). >So the above code would look like: > >#macrowithbody loop($times) #begin > #count $i from 1 to $times { > $body > } >#end > ><CENTER> >#set $piramid="" >#loop(7) { > #set $piramid="$piramid@" > $piramid<BR> >} ></CENTER> > >which in my opinion is much intuitive. > >I will anyway see the directive programming tutorial, seems pretty >interesting. Thank you! > >Regarding macro includes: > >my main WMs go like this: > >#Include as macro "header.wmi" >wm code and html >some includes in the main body of the wm may appear. >#Include "footer.wmi" > >So, what I did is to include de macros in the header, and include the header >as a macro too, dispite it is mixed (macros and normal code). This enables >macros at the main body of the wm automatically. But the included wms inside >it, need to include the macro again. So it seems it is not a per request >include (the macro definition) but a per file include in order for the >compiler/parser to know exactly what code gets expanded per file. >perhaps if there was a way to make a late bound of the included wmi >(on-the-fly parsing) it would not be needed to include the macros in each >file... but to me, it seems much better to have a configuration option to >include macros globally. Which for sure would give performance enhancement. > >Cheers! > >Dario. > > >----- Original Message ----- >From: kea...@na... >To: lib...@in... ; web...@li... >Sent: Wednesday, March 05, 2003 19:36 >Subject: [Webmacro-devel] RE: Passing a block to a macro? > > >Dario, >I'm not the macro expert, so someone else should probably chime in. I'm >pretty sure you only need to declare your macro once per context (i.e., >request). Using an #include is probably the preferred way. There has been >discussion of implementing global macros, but this is still in the >discussion stage. >You are correct that you cannot directly use a block as an argument to a >macro call. (Your #setblock work-around is right on.) You might want to >consider changing your macro to a directive, which would allow you to use a >block. E.g., >#xsltranform stylesheet="/myFile.xsl" { > <xmltag name="hello" value="$myvar"/> >} >This could make a pretty cool addition to WM. Directives aren't really too >hard to create. See http://www.webmacro.org/PluggableDirectiveMechanism and >look at the source for some simple directives. >Hope this helps. >Keats > > >-----Original Message----- >From: Dario Liberman [mailto:lib...@in...] >Sent: Wednesday, March 05, 2003 2:26 PM >To: kea...@na...; web...@li... >Subject: Re: [Webmacro-devel] special characters - now slash directory >separator problem > > >Keats, Thank you very very much. >By the way... I am using macros now :-) >I am supposed to include the macro file in all my files??? >Also, including it in the main wm, does not heredate it to its internal >included files. So it seems that not only the main wms, but really all wms >need the macro include statement, right? >It would be nice to have it included in my configuration file or something >for global access. >Also, is there any way to make a macro with body? >by now, instead of for example doing: >#ApplyXSL ("http://myfile.xsl") { > <xmltag name="hello" value="$myvar"/> >} >I am doing this: >#setblock as macro $thebodyblk { > <xmltag name="hello" value="$myvar"/> >} >#ApplyXSL ("/myfile.xsl", $thebodyblk) >The first sintax is much nicer I beleave. There shoud be a directive that >creates a macro with body, say.. #macrowb >the people at freemarker, I think use the word "nested" to refer to the >bodyblock during the macro definition. > > >When I finish this ApplyXSL tool (I hope to have the time to do it), I will >expose it to the list, maybe someone likes it. >Cheers, >Dario. > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman Conga Spec Sheet: http://opendoors.com/conga/2.2/docs/CongaSpecSheet.pdf Java Software Portal: http://opendoors.com How I expended my youth: http://opendoors.com/lane.pdf |