Can you give an example of what you mean ("macros with bodies")?
Best,
WILL
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
Sent: Tuesday, January 03, 2006 11:34 AM
Subject: Re: request for comments on Macro issues
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 <[EMAIL PROTECTED]> 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.
WILL
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
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 <[EMAIL PROTECTED]> wrote:
> I posted a little note about the JIRA issues on macros on the wiki
>
> http://wiki.apache.org/jakarta-velocity/MacroIssues
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
