(I am hoping this is regular non-HTML mail.  I am at a client site, and I
can't change Outlook's settings.  If this doesn't work, please accept my
apologies, and let me know : I will just telnet to their SMTP port...)

 Leon Messerschmidt [SMTP:[EMAIL PROTECTED]] wrote :
>
> But after a bit of thought I came up with the problem with maintenance.
> Without #macro's in a template you know that the only place something can
go
> wrong is in the Java code.  If you add #macro to templates you inevitably
> add the ability to include libraries of #macro's and therefore another
layer
> of potential bugs.

Sure.  To be precise, the #macro()'s are nothing more than template code, so
I don't quite see why they are worse than using #include.

> [snip]

> Would it be possible to add a property to the velocity.properties file
that
> would allow / disallow #macro's?  I feel that this property should
disallow
> #macro's by default.  Only when a guy understands Vel well enough to
change
> the .properties file is he entitled to use #macro :-)

Yes, that was briefly detailed in the recent 'Velocimacro Proposal mkII',
towards the bottom.  There are 4 current properties pertaining to :

   1) location of global library of VMs that would be read at init.
   2) location of local library of VMs that would be read at init.

   See the proposal to what the difference is.  Note that if the global and
local libraries are not specified in the properties file, then there will be
no VMs added during engine init.  Further there are no 'builtin' VMs either.

   3) boolean allowing inline #macros.  'Inline #macros' are #macro
statements found either explicitly in user templates, or brought in through
an #include.  In short, this controls whether macros can be defined after
initialization of the Velocity engine is complete.

  4) boolean allowing inline #macros to replace VMs defined via the global
or local library that might have been read at init.  Note that for this to
be useful, inlines must be allowed in the first place.

So, the site admin (who presumably controls the .properties), has complete
control : VMs can be supplied only through a 'central library',  have
addition VMs added by user-designer templates, or have the who facility
turned off.

geir


Reply via email to