ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: How about ${fromRefId:some-reference}?
Date Fri, 04 Sep 2009 11:25:04 GMT
>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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message