Re: [Webmacro-devel] RE: Passing a block to a macro?

[Dario L. <lib...@in...>]

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.