I posted a little note about the JIRA issues on macros on the wiki
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

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.

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
I posted a little note about the JIRA issues on macros on the wiki

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: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

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.)

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

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
I posted a little note about the JIRA issues on macros on the wiki

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: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

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.

1/3/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
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.)

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

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
I posted a little note about the JIRA issues on macros on the wiki

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: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

Can you give an example of what you mean ("macros with bodies")?

Best,
WILL

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/3/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
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.)

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

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
I posted a little note about the JIRA issues on macros on the wiki

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: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

#macro( minilayout $style )
a bunch of stuff
<div style="$style">
${BDY}
</div>
a bit more stuff
#end

#minilayout( "color: red;" )
This stuff should be rendered and then inserted where the "BDY"
reference is in the macro definition.
#end

at least, that's a rough idea. the body insertion part might be done
differently than a simple reference.

1/3/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
Can you give an example of what you mean ("macros with bodies")?

Best,
WILL

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/3/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
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.)

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

Message
From: "Nathan Bubna" <nbubna (AT) gmail (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) 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.

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
I posted a little note about the JIRA issues on macros on the wiki

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: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

+1 on the 1.5 macro release approach.

I would also love to see the macro with nested content (I think we are
talking about the same thing) brought in into a Velocity 1.6 release.

In FM they are referred to as the nested directive

regards Malcolm

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org