velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <nbu...@gmail.com>
Subject Re: request for comments on Macro issues
Date Wed, 04 Jan 2006 01:13:12 GMT
#macro( minilayout $style )
a bunch of stuff...
<div style="$style">
${BODY}
</div>
a bit more stuff...
#end


#minilayout( "color: red;" )
This stuff should be rendered and then inserted where the "BODY"
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.

On 1/3/06, Will Glass-Husain <wglass@forio.com> wrote:
> Can you give an example of what you mean ("macros with bodies")?
>
> Best,
> WILL
>
> ----- Original Message -----
> From: "Nathan Bubna" <nbubna@gmail.com>
> 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 <wglass@forio.com> 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" <nbubna@gmail.com>
> > 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 <wglass@forio.com> 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: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Mime
View raw message