On 6/22/07, Matt Benson <[EMAIL PROTECTED]> wrote:
Let me divert the topic for a moment--the other of the
two most important property handling extension points
can be expressed with a PropertyEvaluator interface.
A perfect example is Ant's built-in toString:refid
property "syntax". Basically that's an example of a
custom PropertyEvaluator that interprets a string
beginning with "toString:". Now imagine a
complementary custom property evaluator that evaluates
"refid:refid" to the Object reference. Overload
IH.setAttribute to allow Object values. Change
property replacement such that a string whose entire
contents are a property that evaluates to an Object,
returns the Object. With the postulated refid:refid
PropertyEvaluator, "${refid:myclasspath}" would return
the Path at refid myclasspath. If RuntimeConfigurable
calls the PH method that is capable of returning an
Object, then passes that Object (or String) to the
overloaded IH.setAttribute(), we have just rendered
all classpathref attributes obsolete; rather, any task
can support ref'd types in attributes without having
to support the foo|fooref paradigm. If the attribute
isn't settable as the returned Object, convert the
Object to a String and pass it to the original
IH.setAttribute() implementation.
This use case I do care about. But I always felt refid handling should
be transparent to the tasks, and handled directly by the framework.
hard to retrofit on the current infrastructure though I think. But
where I'm getting at is that this particular example of yours, yes, I
agree it's a valid use case, but I don't think that the way to enable
it ;-)
I'm not overly fond of "special" handling in IH when the attribute
value is "entirely" a property deref, but I could live with that is
others accept it. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
