Stefan Bodewig wrote:
Sorry, for taking that long to come back,
Scott Sanders <[EMAIL PROTECTED]> wrote:
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.
I didn't mean to kick off the creation of a more generic task, I was just concerned that the name xpath would be too generic for what it does.
If you want to extend it to be that generic, fine. An alternative would be to find a better name and keep the current implementation 8-)
I actaully need to extend it ;-)
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?
I depends on how you think about these tasks - I'd rather group tasks by what they do (replace, set properties, whatever) than how they do it. Using this approach there wouldn't be much room for a generalized xpath task but the functionality had to be spread across several existing tasks.
That being said - it really is up to you. I wouldn't veto a generic
xpath task and I'd probably commit it sooner or later. You just need
to find out, what you really want and need.
If replacing is all that is required right now, I'd be happy to simply use a different name for the task like Stephane has submitted it.
I also need to get the value of an xpath expression to set into a property, so I think that it could go both ways, so I will do the easy one for now ;-)
Scott Sanders
