Jose Alberto Fernandez wrote:
>
> > 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.
What prevents two of those people from making two different jars with
code using the same hierarchical namespace? Nothing, other than your
development process, which I am sure prevents that. For example, you
have one source tree?
I think you are reading a bit into this log bit - should I infer from
your response that you don't test anything, just schlep it out into
production and hope for the best? :) I don't really infer that, for
what it's worth.
The above was simply that it can be a manageable problem during
development, and when a collision does occur, you don't have to put in
debugging code or use a debugger to see what happened, but turn first to
the log. That's all.
> 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.
<sigh> I agree. The worst case will be in more of a unmanaged
environment, say on a box shared by multiple clients of an ISP or
something.
I think the inline-macro-only-usable-by-defining-template strategy is
doable.
>
> > > 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.
That's right. It wasn't meant to address the issue you are bringing up.
I assume you do the same thing for servlet bugs. (Not that I think they
are equivalent.)
> Is that how you persive the product will be used?
I think of it more as a 'tool' than a 'product', and personally wish to
see many of the issues that I believe are more 'framwork' related to be
handled by a framework environment. This is probably not one of those
issues, and I *agree* that the
inline-macro-only-usable-by-defining-template is a good thing. But
people have concerns too.
> > 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.
Not necessarily, but yes, that was the stated position of a few people
when it came to the original VM implementation.
> 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.
Noted, and I think that there are cases where this is indeed true. I
would like to do the inline-macro-only-usable-by-defining-template
mechanism, and will probably try to do it, and present it for
discussion.
(Where does the geek thing come into it....?)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
