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 19:34:32 GMT
sounds good.  and i agree it would be nice to be able to #parse a
macro file and have them work in the parent template.

another thing that might be good to keep in mind for 1.6/2.0 when we
address some of these macro design issues is the possibility of
supporting macros with bodies.  i know that's likely to be 2.0 stuff,
but i figure it doesn't hurt to keep it in mind. :)  and i'll be more
eager to help with that.

On 1/3/06, Will Glass-Husain <> wrote:
> Thanks, Nathan...
> Appreciate the feedback - I was indeed looking for these types of general
> comments rather then specific technical points.  Also, I wanted to point out
> to the community that we've had repeated bug reports on this item and "it's
> a feature not a bug", i.e. it's an issue with the design instead of an
> easily fixable bug.  (Rather than just keep these notes in my work journal I
> thought I'd post them to the Wiki.)
> On thinking about it, I'm not eager to do extensive rewrites in
> functionality (at this point) for 1.5, so these issues may get pushed back
> to 1.6 or 2.0 unless there's a revolt.   Ultimately, I'd definitely like to
> see this work in a common sense way (i.e. be able to #parse a file with
> macros).  But in the meantime we can point user's to this Wiki article.
> ----- Original Message -----
> From: "Nathan Bubna" <>
> To: "Velocity Developers List" <>
> Sent: Tuesday, January 03, 2006 8:51 AM
> Subject: Re: request for comments on Macro issues
> 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
> thoughts...
> 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,
> >
> > WILL
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message