> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> On Thursday 14 August 2003 17:44, Dominique Devienne wrote:
> > > -----Original Message-----
> > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > >
> >
> > >
> > > All of the expansions happen later on. If the macro is used in a
> > > different project to the project it is defined in, the
> properties in
> > > use will be of the project that the macro is used in*.
> >
> > Which is exactly why I don't like using the same syntax,
> which until
> > now
> > *always* expanded as if at the place of definition/use!!!
>
> What I am saying is that even with a different notation for
> attributes, normal property resolution will take place in the
> context of the user of the macro, and not when the macro is
> defined. This is a consequence of the way <macrodef/> is
> implemented, in particualar to support embedded elements.
>
Now that you explained this, I would really like to have a way
of defining properties that are expanded at definition time.
I do not know if it can be done with the syntax we already have
or we need something diferent. Probably we do, since we would need
a way to distinguish between inlined (replace during definition)
and not inlined (replaced during evaluation) properties.
> >
> > > However, I can see
> > > that there can be issues with using the same notation for
> the macro
> > > expansion of attributes and then normal expansion of properties.
> >
> > So we're you planning on refusing 'normal' property expansion in
> > <macrodef>? If two different syntax are used, it's obvious what's
> > what.
> >
> > > I am loath however to adding new rules for indicating variables.
> > > However if ant people want a different encoded for the macro
> > > variables, I would have no objection.
> >
> > OK, let's see:
> > 1) Introduce a new syntax (@name) for a new feature,
> > thus keeping the existing syntax ${name} its only behavior
> > 2) Overloading the existing ${name} syntax to behave differently
> > in <macrodef>
> >
> > It's a no brainer to me. I clearly vote for (1).
>
> As a temporary measure I have added a new attribute
> "attributestyle" to allow the notatation to be specified. The
> attribute can be "ant" (default) or "xpath". This should
> allow people to experiment with either formats, and we could
> choose one later.
>
I think this is the worst thing to do. Having flavors of the task will
only
cause confusion I am afraid. We should hash out our differences and
stick to one syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
