On Jan 28, 2010, at 11:19 PM, Stefan Bodewig wrote:
On 2010-01-28, Matt Benson <gudnabr...@gmail.com> wrote:
Okay, using custom PropertyEvaluators (e.g. the "types" evaluator
from
the props antlib) we can set an attribute of a task or type to an
arbitrary Ant type. I would like to (after 1.8.0, I suppose) add a
resource implementation that simply allows one to say, e.g.:
<parsedresource parse="${file(foo.txt)}" />
Now, programmatically, this type is ridiculously trivial:
public class ParsedResource extends ResourceDecorator {
public void setParse(Resource r) {
addConfigured(r);
If macrodef could be used to define types it could wrap around
<resourcelist>
<string value="$${file(foo.txt)}"/>
</resourcelist>
as well.
Nice solution--I thought Peter had submitted a BZ report with a patch
for macroing types, but I can't find it now. I had forgotten about
resourcelist, but it does look like what you've proposed is a capable
solution, and gives us the ability to do what I've suggested without
having to create anything new.
From a code perspective, this can be interpreted as simply
implementing a means of specifying the decorated resource as a bean
property, as an alternative to calling a method. And the "parsed"
mechanism only comes into play if the user consciously chooses to
configure Ant's PropertyHelper appropriately. So I'm searching for a
better name for this concept.
You know I'm not really into names ...
My gut feeling is that there should be a way to do it with/by
extending
a built-in resource rather creating a new one. And then it occured to
me that the <property> resource would be a great fit.
Maybe it would be better (from a naming perspective) if you could do
<property name="file(foo.txt)"/>
instead. I realize this would require bigger code changes.
Yeah, quite... although I think you've identified a--I hesitate to
say "critical", but... "indisputable"--shortcoming in the current
PropertyResource implementation in light of the recent PropertyHelper
changes. I have to concede that it is perfectly reasonable to
expect, given PropertyHelper's ability to resolve arbitrary Objects,
that such a resolved property ought to transparently behave as the
parsed Resource, including name and all other properties. I will
code this ASAP and commit when I finish or after 1.8.0 is released,
whichever is later. While I do think this behavior is a reasonable
expectation once a user has thought of it, I wouldn't necessarily
call it the most obvious think either, so another solution might
still be in order.
The other idea I had was to add the functionality to the <resources>
resource collection, where the implementation would be as trivial as
shown in your code.
<resource add="${file(foo.txt)}"/>
Your paragraph says <resources> but your example uses <resource>; I'm
going to assume you mean the latter. <resource> is, of course,
already available for using references. A solution using this
approach might be to make ResourceDecorator concrete, add a resource
property setter for XML attribute accessibility, redefine a
ResourceDecorator to, by default, refer to itself and call super
method implementations, and replace the <resource> definition in
types/defaults.properties to point to ResourceDecorator instead of
Resource. This way I think we would be able to overload the
<resource> XML element to accept a property parsed resource in
addition to the refid and brute-force property setting attributes
already allowed. But such convoluted solution, though typical of me,
I fear may elicit some controversy, so let the games begin! ;)
-Matt
(now add becomes the name to talk about ...)
Finally, I'd be delighted if, once a nomenclature is settled upon, if
the community said "hey, this is both trivial from a risk perspective
yet potentially quite useful--let's include it in 1.8.0!", but I
certainly won't insist upon it. ;)
IIRC Antoine hinted he wanted to build 1.8.0 today, so it would be too
late anyway.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
