Stefan Bodewig wrote:
Stephane Bailliez <[EMAIL PROTECTED]> 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
