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. [EMAIL PROTECTED]
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
