Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Costin, > > This raises a question: Are properties whose values are resolved by custom > > PropertyHelpers always converted to Strings? I see that the return type > > of PropertyHelper#getPropertyHook(String, String, boolean) has Object as > > the > > return type. But if that's always converted to a String then my custom > > PropertyHelper will need to make sure that this is done correctly, i.e. > > that the Object yields a meaningful String representation. > > > > But for tasks which have a setXXX(Object) method it would maybe make sense > > to preserve the property value as an Object instance, if that's what's > > actually in the buildfile. E.g. > > > > > > > > would not convert the ${my:bar} property to a String. > > If you read the comments on top of PropertyHelper - that was one of the > goals, but I don't think it is implemented yet. The return value for the > property interceptors is already an object, but the code that does property > replacement doesn't know how to deal with "${prop}". > Thanks for pointing that out; I'd missed it. The question is what to do with things like "${my:foo}bar". It would probably have to call toString() on the Object returned by the property resolution and concatenate it with "bar". So only when specified by itself as an attribute value corresponding to a setXXX(Object) method it will be treated as an Object. (Trying a class cast to the setter's argument type would probably also make sense.) In all other cases you will end up using the String representation. -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Knut Wannheden wrote: > Sounds great! > > In anticipation of this feature I have used a few namespaced properties > for > my custom tasks. And since Ant 1.5 doesn't have any value for these, I've > just made the tasks resolve them explicitly. > > This raises a question: Are properties whose values are resolved by custom > PropertyHelpers always converted to Strings? I see that the return type > of PropertyHelper#getPropertyHook(String, String, boolean) has Object as > the > return type. But if that's always converted to a String then my custom > PropertyHelper will need to make sure that this is done correctly, i.e. > that the Object yields a meaningful String representation. > > But for tasks which have a setXXX(Object) method it would maybe make sense > to preserve the property value as an Object instance, if that's what's > actually in the buildfile. E.g. > > > > would not convert the ${my:bar} property to a String. If you read the comments on top of PropertyHelper - that was one of the goals, but I don't think it is implemented yet. The return value for the property interceptors is already an object, but the code that does property replacement doesn't know how to deal with "${prop}". Costin > Cheers, > > -- > knut > > "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> Dominique Devienne wrote, On 12/08/2003 15.37: >> > I'm also interested PropertyHelper, and in particular Costin's >> > experimental XPath based one. I'd like to be able to define >> > functions (defined as part of an AntLib) to operate directly on >> > property values, kind of like XPath functions, and it sounds like >> > property helper is the way to get this!?!? --DD >> >> Yes. PropertyHelper is a property interceptor, and it simply rocks. >> >> In essence, you register a helper with Ant. Then, at each request for a >> property, each registered helper is asked for the property value in >> turn; the first one that has it, returns it. >> >> A typical one is the xpath one, as you say, that resolves the request as >> an xpath in the Ant Project, if the property starts with "xpath:". >> >> Centipede has been using it for a long time, basically to read an xml >> file as a property in a more powerful way than simply using xmlproperty. >> >> Now we are doing our own helper that reads the Gump descriptor, the >> Maven one, etc and makes them all accessible as a single virtual >> descriptor. In this way Ant users can have any descriptor they want and >> use that to gather properties and infos for the project. >> >> Just an example of the usage of PropertyHelper. >> >> -- >> Nicola Ken Barozzi [EMAIL PROTECTED] >> - verba volant, scripta manent - >> (discussions get forgotten, just code remains) >> - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Yes. PropertyHelper is a property interceptor, and it simply rocks. In essence, you register a helper with Ant. Then, at each request for a property, each registered helper is asked for the property value in turn; the first one that has it, returns it. Completely not following this property helper discussion up to this point so I may be repeating something, (forgive me if I am) but this sounds like the results of the request for a property could change if a new property helper gets added... Does this break immutability? It may be that the value of a property object never changes, but if the value of ${foo} is one thing and then becomes another when a helper is added I suspect whatever you have done is not going to cause this, but what about someone writing a custom task that intentionally adds and removes property helpers. What happens if someone writes a task built on this idea? what happens if the property helper intercepts built in things like ${basedir}? Sounds like the basis for a possible task :). Sounds highly abusable to me... If you have set it up so ant doesn't accept new property helpers after it starts executing the file, then this probably isn't an issue... Just curious, -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Sounds great! In anticipation of this feature I have used a few namespaced properties for my custom tasks. And since Ant 1.5 doesn't have any value for these, I've just made the tasks resolve them explicitly. This raises a question: Are properties whose values are resolved by custom PropertyHelpers always converted to Strings? I see that the return type of PropertyHelper#getPropertyHook(String, String, boolean) has Object as the return type. But if that's always converted to a String then my custom PropertyHelper will need to make sure that this is done correctly, i.e. that the Object yields a meaningful String representation. But for tasks which have a setXXX(Object) method it would maybe make sense to preserve the property value as an Object instance, if that's what's actually in the buildfile. E.g. would not convert the ${my:bar} property to a String. Cheers, -- knut "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Dominique Devienne wrote, On 12/08/2003 15.37: > > I'm also interested PropertyHelper, and in particular Costin's > > experimental XPath based one. I'd like to be able to define > > functions (defined as part of an AntLib) to operate directly on > > property values, kind of like XPath functions, and it sounds like > > property helper is the way to get this!?!? --DD > > Yes. PropertyHelper is a property interceptor, and it simply rocks. > > In essence, you register a helper with Ant. Then, at each request for a > property, each registered helper is asked for the property value in > turn; the first one that has it, returns it. > > A typical one is the xpath one, as you say, that resolves the request as > an xpath in the Ant Project, if the property starts with "xpath:". > > Centipede has been using it for a long time, basically to read an xml > file as a property in a more powerful way than simply using xmlproperty. > > Now we are doing our own helper that reads the Gump descriptor, the > Maven one, etc and makes them all accessible as a single virtual > descriptor. In this way Ant users can have any descriptor they want and > use that to gather properties and infos for the project. > > Just an example of the usage of PropertyHelper. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]