> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>
>
> Jose Alberto Fernandez wrote:
>
> > My point is that in any large shop, you will have people
> using the same
> > name for unrelated macros. "#formatAccount". If they happen to run
> > on the same JVM (or classloader) -- Velocity is not just
> for Turbine and
> > Tomcat -- this people will get into conflicts and no one
> will know what
> > is going on.
>
> Yes and no. One thing to consider is that there are other resource
> collisions that one has to manage in a large shop :
> libraries, packages,
> templates, whatever. VMs would be another. And conflicts
> don't happen
> silently : you can lock out the replacement of a VM if it is already
> defined. This also produces log output, so it's not much of a mystery
> if you watch your log.
>
I do not buy this argument. In Java, libraries, packages, V templates
they all live in a hierarchical namespace (either defined by the
hierarchical file system structure, or the namespaces defined by
Java packages). To just say that you can look in the log file for errors
is just asking people to dealt with the problem in the worst time possible,
once the template in on a production environment.
Remember the clash, most probably, will not be within one servlet usage
of Velocity, but it will only occurr once it is installed and running
along with other apps. To design Velocity to only work that way seems
to be just the wrong thing.
> > In any case, what are the rules when Templates are reloaded?
> > Do I override the macro definition?
>
> There is a runtime property that controls this.
>
What do you mean? If the property allows it, then every template defining
a macro with the same name overwrites the definition on the other template;
if the property disallows it, then the only way to correct a bug in a
macro is to shut down the system, and restart.
Is that how you persive the product will be used?
> Well, that was the exact line of reasoning behind the idea that the
> #macro() statement should not be allowed in a regular template : they
> should be loaded at Velocity start.
>
That would mean that to modify a or add a macro I need to restart Velocity
so much for 24x7 operations.
I may be too much of a computer geek, but I really do not buy the
"simplicity" argument for global macros. To tell you the truth I think
this will make things more complicated for people to manage and understand
in the long run.
Jose Alberto