Velocimacros live!

["Geir Magnusson Jr." <ge...@optonline.net>]

After more delay than I wanted, Velocimacro support is now working in
Velocity.  This should be short, meant to give a brief overview.  More
docs will follow. (I am sure Mr. Castura will futher add to the docs
already on the website.)

Velocimacro's are best demonstrated rather than described, at least at
this hour.  

To define a Velocimacro (hereafter 'VM'), the #macro() directive was
added :

#macro( vmname arg1 arg2 )
   <VM VTL code>
#end

where 
1) vmname : name that will be used to call the VM, just like a directive
(#vmname)
2)  arg1 arg2 : arguments to the VM.  A VM can have any number of args,
but the number used at invocation must match the number specified in the
definition.
3) VM VTL code : any valid VTL code - anything you can put into a
template, you can put into a VM

and then to use, you would use it like any other VTL directive in your
template :

#vmname( arg1 arg2 )

VMs can be defined in either a 'global library', a 'local library', or
'inline' in a template.  The global library and local library are
equivalent; the intention of the global library is to have a place for
useful VMs that we want to include in the Velocity distribution, whereas
the local library is for local, site-specific VMs.  Inline VM
definitions are those found in regular 'user' templates.

So for a concrete example, the following is a complete template that
shows how to define a VM inline and then use it :

-- start : don't include this line (well, you can if you want to... it's
velocity!) --

## The following is a macro that takes two arguments
## a color and an array.

#macro( tablerows $color $data )
#foreach($el in $data)
  <tr><td bgcolor=$color>$el</td></tr>
#end
#end

##  now to use it...

#set $names = ["bob","sue","jim"]
#set $color = "blue"
<table>
#tablerows( $color $names )
</table>


-- end : don't include this line --

The output will be :

<table>
  <tr><td bgcolor=blue>bob</td></tr>
  <tr><td bgcolor=blue>sue</td></tr>
  <tr><td bgcolor=blue>jim</td></tr>
</table>

Note : you can test this anywhere, but if you test in the test/misc
directory, you should remove the velocity.properties file.  It isn't
currently correct, and interferes in an ugly way with template issues.  

There is a global library defined in the default Velocity properties
called VM_global_library.vm.  It is a regular template file, is found in
test/templates and when put into the template path (generally, the local
directory), will automatically add the VM 'quietnull'.  quietnull is
defined as follows :

#macro( quietnull $foo)
#if($foo)$foo#end
#end

For those awake among us, this is merely a long way of doing $!foo.  It
can be used as you expect

#quietnull($flargh)

and will output the value of $flargh if it has one, otherwise nothing.

It's just there as an example of how you can define a VM in the
global/local library, and  just use it like a directive in any template.

More stupid VM tricks can be found in test/templates/velocimacro.vm,
part of the testbed.

The current properties that control VMs :

velocimacro.library.global : name of global VM template library.  Like
any other template, must be found in the template path.

velocimacro.library.local : name of local VM template library.

velocimacro.permissions.allowInline : true/false (default true) :
determines if inline VM definitions (#macro directives) are allowed in
regular user templates

velocimacro.permissions.allowInlineToOverride : (true/false) default
false : allow inline (in-template) macro definitions to replace existing
VMs

Note : VMs *cannot* replace control directives (if, else, elseif) or PDs
(foreach, include, parse).

More docs will follow.  Questions welcome and comments please...

geir


-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: Velocimacros live!

[Christoph Reck <Ch...@dlr.de>]

After a second look to VMs, why is the syntax without commas?
Yes its overhead, but using them is standard in most (programming)
languages.

:) Christoph

> To define a Velocimacro (hereafter 'VM'), the #macro() directive was
> added :
> 
> #macro( vmname arg1 arg2 )
>    <VM VTL code>
> #end
>
>[snip]
>
> #vmname( arg1 arg2 )

Re: Velocimacros live!

[Daniel Rall <dl...@finemaltcoding.com>]

"Geir Magnusson Jr." <ge...@optonline.net> writes:

> "Daniel L. Rall" wrote:
> > 
> > "Geir Magnusson Jr." <ge...@optonline.net> writes:
> > [ snip aimless chatter ;) ]
> > > I don't quite get you here.  Can you provide an example?  Are you saying
> > > something like :
> > >
> > > #set $foo = #tablerow( $a $b )
> > >
> > > such that
> > >
> > > <table>
> > >   $foo
> > > </table>
> > >
> > > outputs (for example)
> > >
> > > <table>
> > >   <tr><td color=$a>$b</td></tr>
> > > </table>
> > >
> > > (assuming what tablerow does, of course...)
> > >
> > > Actually, that's *very* possible, if you want the LHS of the #set
> > > assignment simply to 'catch' what the VM would render.  If time allows,
> > > I will try to hack that together tonight and see how well it works.
> > > This is, of course, subject to no great opposition from the list
> > > members, but I don't think this is very far at all from  #set $foo =
> > > $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> > > thing.
> > 
> > With the introduction of a feature like this, next thing you know,
> > people will start "programming" in VTL.  I thought that the whole idea
> > behind the Velocimacro was to present an actual interface to reusable
> > VTL snippets that would otherwise just be #parse'd templates with
> > misc. variables set in the containing template evaluated in the #parse'd
> > markup (i.e. to prevent coupling).
> 
> Dead-on true, but people already program in VTL.  I mean, we have
> control structures and assignments in VTL.
>  
> > I like the interface that Velocimacros give to #parse, but worry about
> > the introduction of too many programmatic features to a templating
> > system.  I think that LHS assignment of a Velocimacro evaluation may be
> > going too far.
> 
> I figured there would be a protest.  I don't feel strongly about this,
> but I thought it an intriguing idea, and if it has a use w/o clouding or
> confusing Velocity's simplicity and usability, I guess I am for it.
> 
> My main counter-argument to the above (and I'll try to avoid that
> aimless chatter... :) is the notion of context-tools. [I want to discuss
> this as Velocity standalone - lets not mix in a framework like
> Turbine...]
> 
> The problem I have with context-tools is when they return formatted
> output: if that doesn't break MVC from the 'person-role' aspect (Java
> programmer vs. template designer), it really blurs the boundary.
> I mean, context-tools are cool for all sorts of uses, utilities like
> string manipulation, algorithmic assistance (like rotating through a set
> of values, for ex. rowcolors in a table).  But I think they are a
> piss-poor solution to producing formatted output.  Of course, in some
> instances there may be no choice w/o making the template language
> complicated.  Life isn't simple, I guess.
> 
> Now, if one puts aside the MVS theology for a sec, and accept the need
> for a context tool that produces formatted output on the RHS of a #set,
> then it would seem natural that you should allow the designer the
> ability to create that 'context tool',  since that *is* the job of the
> designer, which could be a VM, or VM-like entity.
> 
> One alternative, maybe, to keep things clear would be to both access VMs
> as directives so you could invoke a VM inplace as #<VMNAME>() or as a
> reference as $<VMNAME>() in anyplace a reference can be used (such as
> the RHS of a #set assignment...).  Dunno.
> 
> Good subject for discussion, I guess.

You win as usual, +1.  ;)

Daniel

p.s. Sorry for the late reply.

Re: Velocimacros live!

[Daniel Rall <dl...@finemaltcoding.com>]

"Geir Magnusson Jr." <ge...@optonline.net> writes:

> "Daniel L. Rall" wrote:
> > 
> > "Geir Magnusson Jr." <ge...@optonline.net> writes:
> > [ snip aimless chatter ;) ]
> > > I don't quite get you here.  Can you provide an example?  Are you saying
> > > something like :
> > >
> > > #set $foo = #tablerow( $a $b )
> > >
> > > such that
> > >
> > > <table>
> > >   $foo
> > > </table>
> > >
> > > outputs (for example)
> > >
> > > <table>
> > >   <tr><td color=$a>$b</td></tr>
> > > </table>
> > >
> > > (assuming what tablerow does, of course...)
> > >
> > > Actually, that's *very* possible, if you want the LHS of the #set
> > > assignment simply to 'catch' what the VM would render.  If time allows,
> > > I will try to hack that together tonight and see how well it works.
> > > This is, of course, subject to no great opposition from the list
> > > members, but I don't think this is very far at all from  #set $foo =
> > > $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> > > thing.
> > 
> > With the introduction of a feature like this, next thing you know,
> > people will start "programming" in VTL.  I thought that the whole idea
> > behind the Velocimacro was to present an actual interface to reusable
> > VTL snippets that would otherwise just be #parse'd templates with
> > misc. variables set in the containing template evaluated in the #parse'd
> > markup (i.e. to prevent coupling).
> 
> Dead-on true, but people already program in VTL.  I mean, we have
> control structures and assignments in VTL.
>  
> > I like the interface that Velocimacros give to #parse, but worry about
> > the introduction of too many programmatic features to a templating
> > system.  I think that LHS assignment of a Velocimacro evaluation may be
> > going too far.
> 
> I figured there would be a protest.  I don't feel strongly about this,
> but I thought it an intriguing idea, and if it has a use w/o clouding or
> confusing Velocity's simplicity and usability, I guess I am for it.
> 
> My main counter-argument to the above (and I'll try to avoid that
> aimless chatter... :) is the notion of context-tools. [I want to discuss
> this as Velocity standalone - lets not mix in a framework like
> Turbine...]
> 
> The problem I have with context-tools is when they return formatted
> output: if that doesn't break MVC from the 'person-role' aspect (Java
> programmer vs. template designer), it really blurs the boundary.
> I mean, context-tools are cool for all sorts of uses, utilities like
> string manipulation, algorithmic assistance (like rotating through a set
> of values, for ex. rowcolors in a table).  But I think they are a
> piss-poor solution to producing formatted output.  Of course, in some
> instances there may be no choice w/o making the template language
> complicated.  Life isn't simple, I guess.
> 
> Now, if one puts aside the MVS theology for a sec, and accept the need
> for a context tool that produces formatted output on the RHS of a #set,
> then it would seem natural that you should allow the designer the
> ability to create that 'context tool',  since that *is* the job of the
> designer, which could be a VM, or VM-like entity.
> 
> One alternative, maybe, to keep things clear would be to both access VMs
> as directives so you could invoke a VM inplace as #<VMNAME>() or as a
> reference as $<VMNAME>() in anyplace a reference can be used (such as
> the RHS of a #set assignment...).  Dunno.
> 
> Good subject for discussion, I guess.

You win as usual, +1.  ;)

Daniel

p.s. Sorry for the late reply.

Re: Velocimacros live!

["Geir Magnusson Jr." <ge...@optonline.net>]

"Daniel L. Rall" wrote:
> 
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
> [ snip aimless chatter ;) ]
> > I don't quite get you here.  Can you provide an example?  Are you saying
> > something like :
> >
> > #set $foo = #tablerow( $a $b )
> >
> > such that
> >
> > <table>
> >   $foo
> > </table>
> >
> > outputs (for example)
> >
> > <table>
> >   <tr><td color=$a>$b</td></tr>
> > </table>
> >
> > (assuming what tablerow does, of course...)
> >
> > Actually, that's *very* possible, if you want the LHS of the #set
> > assignment simply to 'catch' what the VM would render.  If time allows,
> > I will try to hack that together tonight and see how well it works.
> > This is, of course, subject to no great opposition from the list
> > members, but I don't think this is very far at all from  #set $foo =
> > $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> > thing.
> 
> With the introduction of a feature like this, next thing you know,
> people will start "programming" in VTL.  I thought that the whole idea
> behind the Velocimacro was to present an actual interface to reusable
> VTL snippets that would otherwise just be #parse'd templates with
> misc. variables set in the containing template evaluated in the #parse'd
> markup (i.e. to prevent coupling).

Dead-on true, but people already program in VTL.  I mean, we have
control structures and assignments in VTL.
 
> I like the interface that Velocimacros give to #parse, but worry about
> the introduction of too many programmatic features to a templating
> system.  I think that LHS assignment of a Velocimacro evaluation may be
> going too far.

I figured there would be a protest.  I don't feel strongly about this,
but I thought it an intriguing idea, and if it has a use w/o clouding or
confusing Velocity's simplicity and usability, I guess I am for it.

My main counter-argument to the above (and I'll try to avoid that
aimless chatter... :) is the notion of context-tools. [I want to discuss
this as Velocity standalone - lets not mix in a framework like
Turbine...]

The problem I have with context-tools is when they return formatted
output: if that doesn't break MVC from the 'person-role' aspect (Java
programmer vs. template designer), it really blurs the boundary.
I mean, context-tools are cool for all sorts of uses, utilities like
string manipulation, algorithmic assistance (like rotating through a set
of values, for ex. rowcolors in a table).  But I think they are a
piss-poor solution to producing formatted output.  Of course, in some
instances there may be no choice w/o making the template language
complicated.  Life isn't simple, I guess.

Now, if one puts aside the MVS theology for a sec, and accept the need
for a context tool that produces formatted output on the RHS of a #set,
then it would seem natural that you should allow the designer the
ability to create that 'context tool',  since that *is* the job of the
designer, which could be a VM, or VM-like entity.

One alternative, maybe, to keep things clear would be to both access VMs
as directives so you could invoke a VM inplace as #<VMNAME>() or as a
reference as $<VMNAME>() in anyplace a reference can be used (such as
the RHS of a #set assignment...).  Dunno.

Good subject for discussion, I guess.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: Velocimacros live!

["Geir Magnusson Jr." <ge...@optonline.net>]

"Daniel L. Rall" wrote:
> 
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
> [ snip aimless chatter ;) ]
> > I don't quite get you here.  Can you provide an example?  Are you saying
> > something like :
> >
> > #set $foo = #tablerow( $a $b )
> >
> > such that
> >
> > <table>
> >   $foo
> > </table>
> >
> > outputs (for example)
> >
> > <table>
> >   <tr><td color=$a>$b</td></tr>
> > </table>
> >
> > (assuming what tablerow does, of course...)
> >
> > Actually, that's *very* possible, if you want the LHS of the #set
> > assignment simply to 'catch' what the VM would render.  If time allows,
> > I will try to hack that together tonight and see how well it works.
> > This is, of course, subject to no great opposition from the list
> > members, but I don't think this is very far at all from  #set $foo =
> > $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> > thing.
> 
> With the introduction of a feature like this, next thing you know,
> people will start "programming" in VTL.  I thought that the whole idea
> behind the Velocimacro was to present an actual interface to reusable
> VTL snippets that would otherwise just be #parse'd templates with
> misc. variables set in the containing template evaluated in the #parse'd
> markup (i.e. to prevent coupling).

Dead-on true, but people already program in VTL.  I mean, we have
control structures and assignments in VTL.
 
> I like the interface that Velocimacros give to #parse, but worry about
> the introduction of too many programmatic features to a templating
> system.  I think that LHS assignment of a Velocimacro evaluation may be
> going too far.

I figured there would be a protest.  I don't feel strongly about this,
but I thought it an intriguing idea, and if it has a use w/o clouding or
confusing Velocity's simplicity and usability, I guess I am for it.

My main counter-argument to the above (and I'll try to avoid that
aimless chatter... :) is the notion of context-tools. [I want to discuss
this as Velocity standalone - lets not mix in a framework like
Turbine...]

The problem I have with context-tools is when they return formatted
output: if that doesn't break MVC from the 'person-role' aspect (Java
programmer vs. template designer), it really blurs the boundary.
I mean, context-tools are cool for all sorts of uses, utilities like
string manipulation, algorithmic assistance (like rotating through a set
of values, for ex. rowcolors in a table).  But I think they are a
piss-poor solution to producing formatted output.  Of course, in some
instances there may be no choice w/o making the template language
complicated.  Life isn't simple, I guess.

Now, if one puts aside the MVS theology for a sec, and accept the need
for a context tool that produces formatted output on the RHS of a #set,
then it would seem natural that you should allow the designer the
ability to create that 'context tool',  since that *is* the job of the
designer, which could be a VM, or VM-like entity.

One alternative, maybe, to keep things clear would be to both access VMs
as directives so you could invoke a VM inplace as #<VMNAME>() or as a
reference as $<VMNAME>() in anyplace a reference can be used (such as
the RHS of a #set assignment...).  Dunno.

Good subject for discussion, I guess.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: Velocimacros live!

["Daniel L. Rall" <dl...@finemaltcoding.com>]

"Geir Magnusson Jr." <ge...@optonline.net> writes:
[ snip aimless chatter ;) ]
> I don't quite get you here.  Can you provide an example?  Are you saying
> something like :
> 
> #set $foo = #tablerow( $a $b )
> 
> such that 
> 
> <table>
>   $foo
> </table>
> 
> outputs (for example)
> 
> <table>
>   <tr><td color=$a>$b</td></tr>
> </table>
> 
> (assuming what tablerow does, of course...)
> 
> Actually, that's *very* possible, if you want the LHS of the #set
> assignment simply to 'catch' what the VM would render.  If time allows,
> I will try to hack that together tonight and see how well it works. 
> This is, of course, subject to no great opposition from the list
> members, but I don't think this is very far at all from  #set $foo =
> $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> thing.

With the introduction of a feature like this, next thing you know,
people will start "programming" in VTL.  I thought that the whole idea
behind the Velocimacro was to present an actual interface to reusable
VTL snippets that would otherwise just be #parse'd templates with
misc. variables set in the containing template evaluated in the #parse'd
markup (i.e. to prevent coupling).

I like the interface that Velocimacros give to #parse, but worry about
the introduction of too many programmatic features to a templating
system.  I think that LHS assignment of a Velocimacro evaluation may be 
going too far.
-- 

Daniel Rall <dl...@finemaltcoding.com>

Re: Velocimacros live!

["Daniel L. Rall" <dl...@finemaltcoding.com>]

"Geir Magnusson Jr." <ge...@optonline.net> writes:
[ snip aimless chatter ;) ]
> I don't quite get you here.  Can you provide an example?  Are you saying
> something like :
> 
> #set $foo = #tablerow( $a $b )
> 
> such that 
> 
> <table>
>   $foo
> </table>
> 
> outputs (for example)
> 
> <table>
>   <tr><td color=$a>$b</td></tr>
> </table>
> 
> (assuming what tablerow does, of course...)
> 
> Actually, that's *very* possible, if you want the LHS of the #set
> assignment simply to 'catch' what the VM would render.  If time allows,
> I will try to hack that together tonight and see how well it works. 
> This is, of course, subject to no great opposition from the list
> members, but I don't think this is very far at all from  #set $foo =
> $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> thing.

With the introduction of a feature like this, next thing you know,
people will start "programming" in VTL.  I thought that the whole idea
behind the Velocimacro was to present an actual interface to reusable
VTL snippets that would otherwise just be #parse'd templates with
misc. variables set in the containing template evaluated in the #parse'd
markup (i.e. to prevent coupling).

I like the interface that Velocimacros give to #parse, but worry about
the introduction of too many programmatic features to a templating
system.  I think that LHS assignment of a Velocimacro evaluation may be 
going too far.
-- 

Daniel Rall <dl...@finemaltcoding.com>

Re: Velocimacros live!

["Geir Magnusson Jr." <ge...@optonline.net>]

I am CC-ing velocity-dev as well, as this is interesting, and I think I
am going to do it if there isn't too much violent opposition.

Christoph Reck wrote:
> 
> Velocimacros is a great feature!

Cool! (I think so too... :)

> I was slightly hoping these would be invoked as a reference
> (and not a directive) - to be able to use them within a #set
> (similar to a function call)! Well now I'll make my hack on it
> using my poor-man's-parse replacement velocimacro as already
> presented in a previous discussion to do this (setting a
> variable with the outcome of a parse) - or I could define a
> ContextTool $callMacro that will plug to it...

I don't quite get you here.  Can you provide an example?  Are you saying
something like :

#set $foo = #tablerow( $a $b )

such that 

<table>
  $foo
</table>

outputs (for example)

<table>
  <tr><td color=$a>$b</td></tr>
</table>

(assuming what tablerow does, of course...)

Actually, that's *very* possible, if you want the LHS of the #set
assignment simply to 'catch' what the VM would render.  If time allows,
I will try to hack that together tonight and see how well it works. 
This is, of course, subject to no great opposition from the list
members, but I don't think this is very far at all from  #set $foo =
$somecontexttool.blargh($a,$b), so I can't see why it would be a bad
thing.
 
> Now only two simple questions:
> A) Are the velocimacro.library.global and velocimacro.library.local
>    loaded once during servlet life or is it run per request
>    (second being handled with normal template time-outs)?

It's not actually per servlet life, but once per life of the Runtime.  I
guess they are the same thing as the servlet is instantiated by the
container and kept around, but it's the Runtime that instantiates and
'owns' the VMFactory (the 'manager').  No, there are no timeouts.  It's
considered a static library.  My gut on doing that is pretty much -0
tending to -1 as the VM libraries are not supposed to be like static
content (which could change) or templates, which should only be changing
during development, or rarely during production.

> B) Can a speical context (ContextTools) be defined for use within
>    these libraries?

Not quite sure what you mean here, but there is nothing magical about
how these work.  They are rather brutishly primitive, actually.  You
should be able to pass in a context tool reference just like any other
reference.  Contex tools are simply references, as far as the parser
knows...  That should be the same with VMs.  There may be an
instrospection issue, but I really doubt it, as the VM mechanism sits in
front of the introspection etc.  If you can do it in regular VTL, you
should be able to do it in VMs w/o a problem.

> 
> Thanks for any response (otherwise I'll browse the soruces and
> maybe come up with proposals...)

That would be good too! :)

geir

> 
> :) Christoph

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: Velocimacros live!

["Geir Magnusson Jr." <ge...@optonline.net>]

I am CC-ing velocity-dev as well, as this is interesting, and I think I
am going to do it if there isn't too much violent opposition.

Christoph Reck wrote:
> 
> Velocimacros is a great feature!

Cool! (I think so too... :)

> I was slightly hoping these would be invoked as a reference
> (and not a directive) - to be able to use them within a #set
> (similar to a function call)! Well now I'll make my hack on it
> using my poor-man's-parse replacement velocimacro as already
> presented in a previous discussion to do this (setting a
> variable with the outcome of a parse) - or I could define a
> ContextTool $callMacro that will plug to it...

I don't quite get you here.  Can you provide an example?  Are you saying
something like :

#set $foo = #tablerow( $a $b )

such that 

<table>
  $foo
</table>

outputs (for example)

<table>
  <tr><td color=$a>$b</td></tr>
</table>

(assuming what tablerow does, of course...)

Actually, that's *very* possible, if you want the LHS of the #set
assignment simply to 'catch' what the VM would render.  If time allows,
I will try to hack that together tonight and see how well it works. 
This is, of course, subject to no great opposition from the list
members, but I don't think this is very far at all from  #set $foo =
$somecontexttool.blargh($a,$b), so I can't see why it would be a bad
thing.
 
> Now only two simple questions:
> A) Are the velocimacro.library.global and velocimacro.library.local
>    loaded once during servlet life or is it run per request
>    (second being handled with normal template time-outs)?

It's not actually per servlet life, but once per life of the Runtime.  I
guess they are the same thing as the servlet is instantiated by the
container and kept around, but it's the Runtime that instantiates and
'owns' the VMFactory (the 'manager').  No, there are no timeouts.  It's
considered a static library.  My gut on doing that is pretty much -0
tending to -1 as the VM libraries are not supposed to be like static
content (which could change) or templates, which should only be changing
during development, or rarely during production.

> B) Can a speical context (ContextTools) be defined for use within
>    these libraries?

Not quite sure what you mean here, but there is nothing magical about
how these work.  They are rather brutishly primitive, actually.  You
should be able to pass in a context tool reference just like any other
reference.  Contex tools are simply references, as far as the parser
knows...  That should be the same with VMs.  There may be an
instrospection issue, but I really doubt it, as the VM mechanism sits in
front of the introspection etc.  If you can do it in regular VTL, you
should be able to do it in VMs w/o a problem.

> 
> Thanks for any response (otherwise I'll browse the soruces and
> maybe come up with proposals...)

That would be good too! :)

geir

> 
> :) Christoph

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: Velocimacros live!

[Christoph Reck <Ch...@dlr.de>]

Velocimacros is a great feature!

I was slightly hoping these would be invoked as a reference 
(and not a directive) - to be able to use them within a #set
(similar to a function call)! Well now I'll make my hack on it
using my poor-man's-parse replacement velocimacro as already
presented in a previous discussion to do this (setting a 
variable with the outcome of a parse) - or I could define a 
ContextTool $callMacro that will plug to it...

Now only two simple questions:
A) Are the velocimacro.library.global and velocimacro.library.local
   loaded once during servlet life or is it run per request
   (second being handled with normal template time-outs)?
B) Can a speical context (ContextTools) be defined for use within 
   these libraries?

Thanks for any response (otherwise I'll browse the soruces and
maybe come up with proposals...)

:) Christoph

Re: Velocimacros live!

[Jon Stevens <jo...@latchkey.com>]

something to ponder:

velocimacros are an excellent pseudo replacement for XSL functionality

:-)

-jon

Re: Velocimacros live!

[Jason van Zyl <jv...@periapt.com>]

On Mon, 20 Nov 2000, Geir Magnusson Jr. wrote:

> After more delay than I wanted, Velocimacro support is now working in
> Velocity.  This should be short, meant to give a brief overview.  More
> docs will follow. (I am sure Mr. Castura will futher add to the docs
> already on the website.)

Woo hoo!

Here comes the acid test, into Torque go the VMs!

Awesome! Nice work Geir!

-- 
jvz.

Jason van Zyl
jvanzyl@periapt.com