Jose Alberto Fernandez wrote:
>
> Hi,
>
> I am opening this discussion to all, since I would like to
> hear other peoples opinion.
>
> For the kind of translation templates I am trying to build I will
> need to be able to limit the scope of macros defined on a template
> to that template only. In my case I may have multiple people
> writing templates and using the same Velocity runtime but each one
> will be using its own set of unrelated macros.
>
> I do not mean by this that I do not want the avility to have global
> libraries of macros. But that I also need to be able to define
> macros whose scope is limited to the template.
> In other words, each template must have its own local dictionary
> of macros that gets consulted before the global dictionary.
>
> If you need more info about usage escenarios, let me know.
>
I thought about this, something like namespaces, in the beginning of our
VM adventure, and it was panned I think in discussion. I am still pretty
conservative about adding more directives. But I think attitudes have
changed about VMs since their intro, so this is a chance to rehash
this. I am not thrilled about 'local' VMs, as this I think will result
in much confusion for junior people who don't fully understand the
implications of namespaces.
But...
For example, one implementation could be :
When you want to add VMs to a namespace, you start the template with a
new directive, something like :
#vmnamespace( "name ")
(and you can have some convention that if it's empty then defined macros
are local or something)
then follow with the macro definitions
#macro( foo $a )
<blargh>
#end
#macro( bar $a )
<blargh>
#end
This could be in a regular template, or a central library template. I
am happier about seeing these in central library templates more than
regular ones. We can add properties like
velocimacro.library.1.name = lib1.vm
velocimacro.library.2.name = lib2.vm
to add multiple libraries or something.
Then, when you want to use the macros in the namespace :
#<namespace>:<vmname>( args )
so the above would be
#name:foo( $a )
(or omit the <namespace> part if the macro is in the same template...)
Now, other than support in the VM system, the only addition is the new
directive, and of course allowing ':' as a directive identifier
character.
The problem with the above of course is that if you change the name of
the namespace, then you're screwed, as you have to update every use in
every template.
So think also about a directive like :
#usevmnamespace( "name"
)
that would be placed at the beginning of a template, and then you can
invoke the macros as you wish w/o the namespace prefix -> the declared
namespace will be checked...
Again, I think these are useful, but I am not 100% convinced we want to
do this right now. (But the geek in me does :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
