velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <>
Subject Re: request for comments on Macro issues
Date Tue, 03 Jan 2006 16:51:26 GMT
Disclaimer:  This stuff is pushing the edges of my understanding of
Velocity internals; i know how velocimacros behave far better than i
know how they are implemented internally.   So, i'm not sure how
competently i can comment here.  Nonetheless, here are some

I've long thought macros could use a rewrite, but i'm skeptical that
we can do that without breaking some key b.c. stuff.  I suspect it
might be wiser to stick to documented behavior for 1.5 and just fix
what bugs we can for now.  I'm more eager to see a 1.5 release than to
have improved macro design.  That can come later and perhaps be more
thorough then?

Regardless of when it is done, I've no idea if your proposed solution
will work, nor have i time right now to dig into the matter more (no
surprise there, i'm sure).  If you think it will only fix bugs and add
some new way(s) to use velocimacros without breaking the ways they are
currently used, then i say go for it!  That would be very cool.

Your proposed "calling page" scope sounds quite good, but i don't
think it would be wise to have this as the default for 1.5.  We should
stick to the current default for now.

On 1/2/06, Will Glass-Husain <> wrote:
> I posted a little note about the JIRA issues on macros on the wiki
> Once I dug into these issues, I realized the scope of macros seems rather odd.  Specifically,
various users have complained that you can't stick macros in a file called by #parse (I've
run into this myself).  This is documented but still rather unintuititive.  The recommended
action is to put such macros in a library, but that may not be feasible with a large heterogenous
library of templates. (or a case where template writers do not have control of the environment).
> What I realized is that this is fundamentally due to a design issue rather than a bug.
 Would appreciate any comments on this interpretation and my proposed approach to solve this.
> Thanks,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message