ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Sanders <sa...@totalsync.com>
Subject Re: [PROPOSAL] XPath task
Date Fri, 27 Apr 2001 17:20:58 GMT
Stefan Bodewig wrote:

> Stephane Bailliez <sbailliez@imediation.com> wrote:
> 
> 
>> Following discussion w/ Scott and Jeff in alexandria-dev, I quickly
>> wrote an XPath task.
> 
> 
> I'm not comfortable with the name, otherwise I would have committed it
> right now.  What this task seems to do is replacing - xpath is just
> used to find the stuff you want to replace.
> 
> 
>> I'm not sure this is 'exactly' how it should be done...  this looks
>> like more a feature of the replace task, but I also wanted the
>> multiple replace feature without parsing n times the xml document.
> 
> 
> I've not really read through the code, but would it really be that
> difficult to integrate it with <replace>?  The replace task already
> supports multiple replacements via the nested replacefilter element.
> 
> If you say, this would mean a major rewrite of replace and causes too
> much pain ATM, fine, let's make it a task of its own.  But <xpath>
> looks too generic for the type of action it performs (it could as well
> select parts of an XML document and include it/set a property from it,
> whatever).

I agree that xpath is generic, but my idea of an xpath task would be 
nothing on the main element, and then many different types of subtasks, 
such as replace, set a property, check a value, etc.

If that happens, does it make sense to still move the replace 
functionality to <replace>, or to keep all functionality that uses xpath 
under the same task?

If the functionality was extended, do you see it standing on its own?

Scott Sanders




Mime
View raw message