How about ${fromRefId:some-reference}?

[Stefan Bodewig]

Hi,

we have a PropertyEvaluator for ${toString:some-id} that looks up an
object with id "some-id" in the current project and expands to either
null (reference doesn't exist) or the result of calling toString() on
the object.

With trunk PropertyEvaluators can return non-Strings as values for
properties and IntrospectionHelper actually uses this.  Say I have

public void setFoo(MyComplexType t)

as attribute and

<someTask foo="${property}"/>

and a PropertyEvaluator returns an instance of MyComplexType for
"property" then IntrospectionHelper will happily pass that instance
along (if the attribute setter didn't match the whole old
set-from-string logic would be applied to the toString() version of my
property).

This is most useful for tasks that want to accept Resource as an
attribute, all it takes is a property evaluator that returns a Resource
instance.  For example
<http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/propertyhelpers.xml?view=log>
and
<http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/replace-test.xml?view=log>.

I suggest to add another core PropertyEvaluator that works like the one
for toString but doesn't invoke toString() on the reference (but leaves
that to IntrospectionHelper if necessary).

As usual, I'm unsure about the name of the prefix

${fromRefId:foo}
${ref:foo}
${refid:foo}
${fromReference:foo}

...

The ${ref:} and ${refid:} ideas look prettier but are more likely to
collide with existing property names.

Stefan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jan.Materne]

>we have a PropertyEvaluator for ${toString:some-id} that looks up an
>object with id "some-id" in the current project and expands to either
>null (reference doesn't exist) or the result of calling toString() on
>the object.
>
>With trunk PropertyEvaluators can return non-Strings as values for
>properties and IntrospectionHelper actually uses this.  Say I have
>
>public void setFoo(MyComplexType t)
>
>as attribute and
>
><someTask foo="${property}"/>
>
>and a PropertyEvaluator returns an instance of MyComplexType for
>"property" then IntrospectionHelper will happily pass that instance
>along (if the attribute setter didn't match the whole old
>set-from-string logic would be applied to the toString() version of my
>property).
>
>This is most useful for tasks that want to accept Resource as an
>attribute, all it takes is a property evaluator that returns a Resource
>instance.  For example
><http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/
>propertyhelpers.xml?view=log>
>and
><http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/
>taskdefs/replace-test.xml?view=log>.
>
>I suggest to add another core PropertyEvaluator that works like the one
>for toString but doesn't invoke toString() on the reference (but leaves
>that to IntrospectionHelper if necessary).
>
>As usual, I'm unsure about the name of the prefix
>
>${fromRefId:foo}
>${ref:foo}
>${refid:foo}
>${fromReference:foo}
>
>...
>
>The ${ref:} and ${refid:} ideas look prettier but are more likely to
>collide with existing property names.

Because you referencing an id I would prefer ${refid:*}.
There can be collisions as this is possible
  <project>
    <property name="x:foo" value="bar"/>
    <echoproperties prefix="x"/>
  </project>

  [echoproperties] x\:foo=bar

but I think the ':' as seperation character is not a common use case.
But in conclusion that would be a note in the "could break existing
builds" section.


Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ddevienne]

On Fri, Sep 4, 2009 at 6:25 AM, <Jan.Materne@...> wrote:
>>I suggest to add another core PropertyEvaluator that works like the one
>>for toString but doesn't invoke toString() on the reference (but leaves
>>that to IntrospectionHelper if necessary).
>>
>>The ${ref:} and ${refid:} ideas look prettier but are more likely to
>>collide with existing property names.
>
> Because you referencing an id I would prefer ${refid:*}.

Tasks in the past had to explicitly support this by adding a separate
attribute which typically (by convention) uses a "ref" suffix (classpath="...",
classpathref="..."), so having the following two notations
(classpathref="my_cp", classpath="${ref:my_cp}" equivalent leans
towards using ref:.

OTOH, for addFoo() (i.e. nested elements), we use <classpath refid="my_cp"/>,
so that points towards refid:.

Either way is fine with me. classpath="${refid:my_cp}" reads well.

> There can be collisions as this is possible
>  <project>
>    <property name="x:foo" value="bar"/>
>    <echoproperties prefix="x"/>
>  </project>
>
>  [echoproperties] x\:foo=bar
>
> but I think the ':' as seperation character is not a common use case.
> But in conclusion that would be a note in the "could break existing
> builds" section.

We could avoid ambiguity by not using a ${} notation...

I'm not sure I like the fact that ${} would start returning something
else than a String. Then there's classpath="foo${refid:my_cp}bar"...
When you mix literals and a reference, what happens?

I've always considered that expanding references should be
something part of the core, especially when writing all those
xyzref attributes in my own tasks.

Since references are introduced by using an id="abc" attribute,
and that such attributes in HTML are fragment which are accessed
using #abc in URLs, I'd prefer we introduce this notation to expand
references, rather than overloading ${}. #abc or #{abc}, the latter
being more consistent with our existing ${} and @{} notations.

BTW, we already have ${} and @{} which interact in interesting ways,
allowing to do ${foo@{bar}} inside a macro. How would #{} (or ${refid:})
interact here?

Sorry to raise concerns again... I'm just trying to see whether
reference expansion shouldn't be something built-in rather than
tacked on via PropertyHelper. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On 2009-09-04, Dominique Devienne <ddevienne@...> wrote:

> On Fri, Sep 4, 2009 at 6:25 AM, <Jan.Materne@...> wrote:
>>> I suggest to add another core PropertyEvaluator that works like the one
>>> for toString but doesn't invoke toString() on the reference (but leaves
>>> that to IntrospectionHelper if necessary).

>>> The ${ref:} and ${refid:} ideas look prettier but are more likely to
>>> collide with existing property names.

>> Because you referencing an id I would prefer ${refid:*}.

> Tasks in the past had to explicitly support this by adding a separate
> attribute which typically (by convention) uses a "ref" suffix (classpath="...",
> classpathref="..."), so having the following two notations
> (classpathref="my_cp", classpath="${ref:my_cp}" equivalent leans
> towards using ref:.

That would only work if the setter inside the task would accept a Path
argument.

> We could avoid ambiguity by not using a ${} notation...

Ahh, that's what I wanted to keep for a different thread, but now that
you raise it ... see the thread I'm going to start next week ;-)   [1]

> I'm not sure I like the fact that ${} would start returning something
> else than a String. Then there's classpath="foo${refid:my_cp}bar"...
> When you mix literals and a reference, what happens?

You get the same result that you'd get with
classpath="foo${toString:my_cp}bar" today - that's how it is
implemented, at least.

> BTW, we already have ${} and @{} which interact in interesting ways,
> allowing to do ${foo@{bar}} inside a macro. How would #{} (or ${refid:})
> interact here?

If we hook it into the PropertyHelper mechanisms (what I suggested) it
will work just like any other property reference.

> Sorry to raise concerns again...

No reason to be sorry, that's why we discuss this stuff in the first
place.

Stefan

[1] OK, I'd like to provide a String => Resource mechanism, something
    that has been discussed before.  This is trivial for URLs, but we
    need something more generic.  If we wanted to plug it into the
    PropertyHelper stuff (I haven't considered another option so far) it
    would probably be easier if we used or own PropertyExpander in order
    to allow something like #{url:${some.url}}.

    There are still a few things that I haven't thought through, so I'd
    like to defer that discussion for a few days, though.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Matt Benson]

You might also want to check out the refs and types evaluators from the props antlib here... they're a little generic though.

-Matt

--- On Fri, 9/4/09, Stefan Bodewig <bodewig@...> wrote:

> From: Stefan Bodewig <bodewig@...>
> Subject: Re: How about ${fromRefId:some-reference}?
> To: dev@...
> Date: Friday, September 4, 2009, 1:02 PM
> On 2009-09-04, Dominique Devienne
> <ddevienne@...>
> wrote:
>
> > On Fri, Sep 4, 2009 at 6:25 AM, <Jan.Materne@...>
> wrote:
> >>> I suggest to add another core
> PropertyEvaluator that works like the one
> >>> for toString but doesn't invoke toString() on
> the reference (but leaves
> >>> that to IntrospectionHelper if necessary).
>
> >>> The ${ref:} and ${refid:} ideas look prettier
> but are more likely to
> >>> collide with existing property names.
>
> >> Because you referencing an id I would prefer
> ${refid:*}.
>
> > Tasks in the past had to explicitly support this by
> adding a separate
> > attribute which typically (by convention) uses a "ref"
> suffix (classpath="...",
> > classpathref="..."), so having the following two
> notations
> > (classpathref="my_cp", classpath="${ref:my_cp}"
> equivalent leans
> > towards using ref:.
>
> That would only work if the setter inside the task would
> accept a Path
> argument.
>
> > We could avoid ambiguity by not using a ${}
> notation...
>
> Ahh, that's what I wanted to keep for a different thread,
> but now that
> you raise it ... see the thread I'm going to start next
> week ;-)   [1]
>
> > I'm not sure I like the fact that ${} would start
> returning something
> > else than a String. Then there's
> classpath="foo${refid:my_cp}bar"...
> > When you mix literals and a reference, what happens?
>
> You get the same result that you'd get with
> classpath="foo${toString:my_cp}bar" today - that's how it
> is
> implemented, at least.
>
> > BTW, we already have ${} and @{} which interact in
> interesting ways,
> > allowing to do ${foo@{bar}} inside a macro. How would
> #{} (or ${refid:})
> > interact here?
>
> If we hook it into the PropertyHelper mechanisms (what I
> suggested) it
> will work just like any other property reference.
>
> > Sorry to raise concerns again...
>
> No reason to be sorry, that's why we discuss this stuff in
> the first
> place.
>
> Stefan
>
> [1] OK, I'd like to provide a String => Resource
> mechanism, something
>     that has been discussed before.  This is
> trivial for URLs, but we
>     need something more generic.  If we
> wanted to plug it into the
>     PropertyHelper stuff (I haven't considered
> another option so far) it
>     would probably be easier if we used or own
> PropertyExpander in order
>     to allow something like #{url:${some.url}}.
>
>     There are still a few things that I haven't
> thought through, so I'd
>     like to defer that discussion for a few days,
> though.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

Altought it is not explicitely documented, the set of predefined properties
ant.* give the impression that ant. is a reserved prefix.

Maybe ${ant.ref:XXXX} would reduce the risk collisions



Gilles Scokart


2009/9/4 Stefan Bodewig <bodewig@...>

> Hi,
>
> we have a PropertyEvaluator for ${toString:some-id} that looks up an
> object with id "some-id" in the current project and expands to either
> null (reference doesn't exist) or the result of calling toString() on
> the object.
>
> With trunk PropertyEvaluators can return non-Strings as values for
> properties and IntrospectionHelper actually uses this.  Say I have
>
> public void setFoo(MyComplexType t)
>
> as attribute and
>
> <someTask foo="${property}"/>
>
> and a PropertyEvaluator returns an instance of MyComplexType for
> "property" then IntrospectionHelper will happily pass that instance
> along (if the attribute setter didn't match the whole old
> set-from-string logic would be applied to the toString() version of my
> property).
>
> This is most useful for tasks that want to accept Resource as an
> attribute, all it takes is a property evaluator that returns a Resource
> instance.  For example
> <
> http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/propertyhelpers.xml?view=log
> >
> and
> <
> http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/replace-test.xml?view=log
> >.
>
> I suggest to add another core PropertyEvaluator that works like the one
> for toString but doesn't invoke toString() on the reference (but leaves
> that to IntrospectionHelper if necessary).
>
> As usual, I'm unsure about the name of the prefix
>
> ${fromRefId:foo}
> ${ref:foo}
> ${refid:foo}
> ${fromReference:foo}
>
> ...
>
> The ${ref:} and ${refid:} ideas look prettier but are more likely to
> collide with existing property names.
>
> Stefan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Stefan Bodewig]

On 2009-09-04, Stefan Bodewig <bodewig@...> wrote:

> I suggest to add another core PropertyEvaluator that works like the one
> for toString but doesn't invoke toString() on the reference (but leaves
> that to IntrospectionHelper if necessary).

It is in with svn revision 816153

> As usual, I'm unsure about the name of the prefix

Combining Gilles' and Jan's feedback it is ${ant.refid:foo}.

Given that this property evaluator is the very first one added to
PropertyHelper it will be the last one consulted.  This reduces the
possibility of collisions - if anybody used properties with
ant.refid:foo in her build file, this file will work as before with
current trunk.  Only if a build file relied on ${ant.refid:foo} to not
expand to anything and a reference named "foo" exists there will now be
a change of behavior.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Matt Benson]

--- On Thu, 9/17/09, Stefan Bodewig <bodewig@...> wrote:

> From: Stefan Bodewig <bodewig@...>
> Subject: Re: How about ${fromRefId:some-reference}?
> To: dev@...
> Date: Thursday, September 17, 2009, 11:07 PM
> On 2009-09-17, Matt Benson <gudnabrsam@...>
> wrote:
>
> > So I take it you don't see any value in making all
> propertyhelper
> > delegates optional, as is the case with those provided
> by the props
> > antlib?
>
> To be honest, that thought never occured to me.
>
> > Or are you concerned about adoption, or...?
>
> If you could make the props antlib leave the sandbox and
> get released,
> that would probably help a lot 8-)

But how to release the cart (props) before the horse (1.8)?  :)

-Matt

>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


     

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...