Here is how I see it.
Christoph Reck wrote:
> If I get this right, VM are currently allways global?
>
> This whould be another reason for making VM access into
> references (using '$' and not '#'). They should be placed
> into something called a 'base context' which is cloned on
> each request. Local VMs are then volatile!
>
> I believe some documentation is needed on the context of
> a VM:
> * Where does a VM live - in the context or in the
> directive look-up-table?
Its own global hashtable
> * What references/variables does it see internally -
> only the passed ones or all of the current context?
Sees all of the current content.
> * What happens with local #set's, are they visible
> after the VM returns?
Yes it changes the current content.
> * What happnes with local #set's when they have the
> same name as in the global context?
It changes it.
> * It seems that it is strongly recommeded to place
> VMs into libraries, which are loaded on startup.
> Local VMs may be used within a template if the
> configuration allows it. The issue of this thread
> is to clarify if these VMs live past this template
> access and are accessible from other templates.
>
> Thanks in advance for clarifications.
My thinking in transforming XML into HTML or some other
using Anikia it to get hold of the start-up content.
Let if parse a template with global settings and macro definitions.
Then pass control to some java function that reads some control file
that ties xpath to macro names. Process these queries, make a copy
of the content between every macro call. With macro names that can duplicate
use 'DomainMacroname'.
This can go a long way without interfering with Velocity, other than
basic filtering issues.
Theo
