Deleting node returned from xmlSearch()

> But, we have found it cleaner and easier to do similar edits on the XML text
> using an REReplace. (We have no child nodes or CDATA to contend with.)

Hi Mike.
I think your opinion of CF's XML support matches mine, by the sounds of it.
It seems a bit of a superficial nod, rather than a well-considered
implementation.

I thought about the regex approach. Indeed for the situation in front of
us where we know (and are in control of) the structure of the XML and the
node we're removing is always going to be fairly simple, the regex solution
would have worked.

Cheers.

--
Adam

Given the limitations of xmlChildPos() and Adobe XPath, I believe that yours is the most concise, XML, way to delete a node by id (unless java offers something better).

But, we have found it cleaner and easier to do similar edits on the XML text using an REReplace. (We have no child nodes or CDATA to contend with.)

> The problem is that the xmlSearch does not return a reference to the
> node(s), but rather an array of copies of the nodes

No it doesn't. They're references to the nodes, not copies. Easy to test:
add/update/delete an attribute in the array, and it is also reflected in
the original XML object.

Along these lines, one can actually do a structClear() on the array element
which gets rid of what's there (so kinda OK), but leaves a null node in the
XML doc, rather than deleting it (which is actually OK for my immediate
requirement, but not a "complete" answer).


> I have found XSLT to be a much cleaner way to do this kind of XML
> modification.

I considered this approach. It still smacks me as a variation of the old
"loop over it until you find it" routine. Which just strikes me as
*wrong*, for a simple node deletion.

My rule of thumb is I avoid looping if I'm not performing the given action
(ie: the code in the loop) on the majority of the items being looped over.
Sure the XSLT abstracts the looping away from immediate scrutiny, but it's
still happening.

But anyway, thanks for coming back to me. It's good to know how other
people deal with these things.

--
Adam

The problem is that the xmlSearch does not return a reference to the
node(s), but rather an array of copies of the nodes that match the xpath
expression.

I have found XSLT to be a much cleaner way to do this kind of XML
modification.

<cfsavecontent variable="y">
<?xml version="1.0" encoding="iso-8859-1"?>

<xsl:stylesheet version="1.0"
xmlns:xsl=" http://www.w3.org/1999/XSL/Transform">

<!-- XSL code to modify the XML in the desired manner -->

</xsl>
</cfsavecontent>


<cfset a = xmlTransform(x,y)>