[PROPOSAL] XPath task

[Stephane Bailliez <sb...@imediation.com>]

Following discussion w/ Scott and Jeff in alexandria-dev, I quickly wrote an
XPath task.

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.

Use at as follows:

<xpath file="input.xml" tofile="output.xml">
	<apply select="/root/node/@attribute" value="newvalue"/>
	<apply select="/root/node/child/@attribute" value="newvalue"/>
</xpath>

or simply:

<xpath file="input.xml" select="/root/node/@attribute" value="newvalue"/>

So here is the XPath task, with testcase and doc.

I used the package org.apache.tools.ant.taskdefs.optional.xpath
Feel free to change it to a more appropriate one (for instance if it is to
be used in cjan or alexandria).

Cheers,

-- 
 St�phane Bailliez 
 Software Engineer, Paris - France 
 iMediation - http://www.imediation.com 
 Disclaimer: All the opinions expressed above are mine and not those from my
company. 

Re: [PROPOSAL] XPath task

[Scott Sanders <sa...@totalsync.com>]

Excellent.  I am also watching the Ant-dev list, so if they do not 
accept it, we will find a place for it ;-)

BTW, that was some fast response, thanks a lot!

Scott

Stephane Bailliez wrote:

> Following discussion w/ Scott and Jeff in alexandria-dev, I quickly wrote an
> XPath task.
> 
> 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.
> 
> Use at as follows:
> 
> <xpath file="input.xml" tofile="output.xml">
> 	<apply select="/root/node/@attribute" value="newvalue"/>
> 	<apply select="/root/node/child/@attribute" value="newvalue"/>
> </xpath>
> 
> or simply:
> 
> <xpath file="input.xml" select="/root/node/@attribute" value="newvalue"/>
> 
> So here is the XPath task, with testcase and doc.
> 
> I used the package org.apache.tools.ant.taskdefs.optional.xpath
> Feel free to change it to a more appropriate one (for instance if it is to
> be used in cjan or alexandria).


---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

Re: [PROPOSAL] XPath task

[Scott Sanders <sa...@totalsync.com>]

Stefan Bodewig wrote:

> Sorry, for taking that long to come back,
> 
> Scott Sanders <sa...@totalsync.com> 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

Re: [PROPOSAL] XPath task

[Stefan Bodewig <bo...@apache.org>]

Sorry, for taking that long to come back,

Scott Sanders <sa...@totalsync.com> 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-)

> 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.

Stefan

Re: [PROPOSAL] XPath task

[Scott Sanders <sa...@totalsync.com>]

Stefan Bodewig wrote:

> Stephane Bailliez <sb...@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

Re: [PROPOSAL] XPath task

[Stefan Bodewig <bo...@apache.org>]

Stephane Bailliez <sb...@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).

Stefan