ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [patch] myrmidon configurer
Date Mon, 14 Jan 2002 10:18:45 GMT
Applied - tah. One interesting thing thing came out of thinking about this is 
that currently all of our convertion is done from strings to the varies 
different values.

ie we have StringToBoolean, StringToLong, StringToFile etc

Something that maybe an idea to thing about is 


Not sure if that is useful though .. probably not but just thought I would 
bring it up.

Another thing that is interesting. Currently all the following are equivelent 
(assuming the presence of proper converters

1. <foo bar-ref="x"/> 
2. <foo bar="${x}"/>
3. <foo>
    <x-ref id="x"/>

I was wondering whether we should support (2). (2) mainly happens because the 
value of ${x} is resolved to an object but there is  no character data 
between the " marks. However if it had been represented as

<foo bar="${x} "/> <!-- note the extra space -->

then you would have a completely different value. Maybe we could say that if 
after resolving a value we end up with an object then we always call 
toString() on it. Thoughts?

On Sun, 13 Jan 2002 10:42, Adam Murdoch wrote:
> Hi,
> A couple of changes to the configurer in myrmidon:
> * Handle references.
> References can appear as either an attribute or a nested element of an
> object:
> As an attribute:
> <javac classpath-ref="some-classpath">
> As a nested element:
> <javac>
>     <classpath-ref id="some-classpath"/>
> </javac>
> * Unify attributes and elements at the task interface.
> This patch changes the configurer so that the addX() and setX() methods
> have the same semantics.  Each addX() or setX() method defines a property
> X, which can appear as either an attribute x or as nested <x> elements (or
> both).
> There may also be createX() method, which is used to create the property
> value to be configured.  A property with a createX() method may only appear
> as a nested element.
> A quick summary of how the configurer configures an object:
> - For each attribute x-ref="id":
>   - looks up the object using "id".
>   - sets the value using setX()/addX().
>   - this cannot be used if the object has a createX() method.
> - For each attribute x="value":
>   - resolves property references in the value.
>   - converts the string value into the correct type.
>   - sets the value using setX()/addX().
>   - this cannot be used if the object has a createX() method.
> - For each nested element <x-ref id="id"/>:
>   - handled the same as attribute x-ref="id".
> - For each nested element <x>:
>   - creates the value using the createX() method (if present) or the
> no-args constructor.
>   - configures the value using the nested element.
>   - sets the value using setX()/addX().
> This is really only intended to be a temporary solution.  I'd like to go
> through and standardise on either addX() or setX(), and possibly look at
> doing away with the createX() method.  And there's plenty more stuff yet to
> be implemented.
> Adam
> ps. Not sure how to show deleted files with cvs diff, so here are the files
> that have been deleted/renamed:
> AttributeSetter
> DefaultAttributeSetter
> ElementSetter
> DefaultElementSetter



    If your life passes before your eyes when you die, 
 does that include the part where your life passes before 
                        your eyes?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message