Apologies in advance for this coming from MSFT Outlook. I am at a client and this is what I have to use here.
-----Original Message-----
From: Fedor Karpelevitch [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, October 03, 2000 2:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Proposal for New Velocity Functionality
"Geir Magnusson Jr." wrote:
>
> Below is a (long) proposal for macro capabilities for Velocity.
[snip]
Actually there was third one discussed here: formatters;
This problem can be gracefully solved within formatter concept by defining formatters for all null values or for null values for variables matching particular mask.
It is completely configuration-based so this need not be taken care of by template designer and you can configure different behavior in different environments (display err message in development but silently skip it in production) without _any_ changes in
templates. I believe such behavior is often desirable.
I remember people criticizing, for example, freemaker for the ability to define functions, and I totally agree with it. KISS. Let's not make Velocity another mammoth. Macroses just do not belong here.
So, as you could guess I am strongly -1 if I have a vote.
WBR, fedor.
There are two things here that I can try to address. I have seen related concerns in other responses to the Proposal, previous list discussions, and IRC discussions.
First, this won't change the 'surface area' of Velocity itself very much. The only addition to the VTL to support VM's is the propsed #macro (or #defineVM) directive which allows one to define a VM . As this would be valid VTL, the VM's could be defined in a designers' template in-line or in a central library, either provided by the distro or specified by an uber-designer. In all three cases, the vehicle in which the VM is defined/declared would be the same thing : namely a regular Velocity template. The internals of Velocity to handle all three would be the same : if configured to do so via the properties, it would simply read the central library template at startup. The VM's can be added dynamically, which is why it could work that way. And because properties can control the use of all three modes, the admin still has control over this feature.
Granted, the 'local surface area' of Velocity then is up to users : if they wish to define a large library of VM's, I think so be it. It won't involve anyone *but* the designers. I agree with the philosophy of limiting the trouble a designer can get in via a simple toolset, but I think that forcing them to cut and paste the same VTL/HTML constructs throughout a multi-template project is actually doing them a disservice when something as simple as a VM can help them out.
Second, and maybe related, there has been some concern expressed about performance and overhead. I don't feel that there will be much overhead : each VM is kept internally as a string literal, and gets patched, parsed and rendered dynamically at run time. (This has to happen because the args to the VM can be different references from use to use...) So the storage overhead for a VM is very small. I have been thinking about all sorts of optimizations, but I would like to do some performance testing tonight to see if there is a baseline cost of using VM's in a template before proceeding. I will be happy to report the results here if anyone is interested.
( I have been using 'VTL' for 'Velocity Template Language'. I have seen others use 'VTM', 'M' for macro I suspect, but that will be confusing with 'VM' for Velocimacro... I haven't been around long here, so if VTM is the standard, I will stop using VTL....)
geir
