XMLDOM - update node value via javascript/html - Javascript

On Oct 11, 3:45 am, "kevinfa...@googlemail.com"
<kevinfa...@googlemail.com> wrote:
> Quite a newbie to DOM and activex objects in javascript:
>
> I have a requirement to write a piece of code which is capable of
> reading in a node value from an xml file, performing some mathematical
> functions on it, and then saving back to the same node.
>
> I've got the node reading and the mathematical functions, I'm
> struggling with the write back to xml. I have permissions on the
> server to write to the file, so that's not an issue.
>
> code so far is as thus:
>
> //get xml file and get hit node
> var xmlDoc = new ActiveXObject("Microsoft.XMLDOM")
> xmlDoc.async="false"
> xmlDoc.load("hit.xml")
>
> //increment hit node by 1
> hits = (xmlDoc.documentElement.childNodes.item(0).text)
> hits = hits * 1
> hits = hits + 1
> document.write(hits)
>
> XML file as thus:
>
> <?xml version="1.0" ?>
> <Counter>
> <hits>0</hits>
> </Counter>
>
> any help would be greatly appreciated.

To manipulate files on the webserver, it'd be better to use a server-
side scripting language. ActiveX objects only work in IE.
Personally, I would have a hidden image tag in my document that had a
url in its src attribute that pointed to a page that read and
incremented the xml using a server-side language like ASP or PHP.

<IMG style="display:none" src="URL_FOR_COUNTER_PAGE_HERE">

As for the processing in the counter page, I'd:
* Read the xml file into a string
* Search the string for "<hits>" and save the position following the >
* Search the string for "</hits>" and save the position before the <
* Get the text between the saved positions and convert it to a number
* Increment the number
* Build a new string and write it back to the file

How to achieve the steps above would vary depending on which server-
side language you used.

drink.the.koolaid wrote:

> <kevinfa...@googlemail.com> wrote:
>> //get xml file and get hit node
>> var xmlDoc = new ActiveXObject("Microsoft.XMLDOM")
>> xmlDoc.async="false"
>> xmlDoc.load("hit.xml")

This would fail in any non-Microsoft browser; the recommended way is
to feature-detect the object and execute alternative code in case of a
non-flag (see below).

>> //increment hit node by 1
>> hits = (xmlDoc.documentElement.childNodes.item(0).text)
>> hits = hits * 1
>> hits = hits + 1
>> document.write(hits)

This also appears to work in MSIE only. I think the following is
better:

var hits =
doc.documentElement.childNodes[0].childNodes[0].nodeValue;

>> XML file as thus:
>
>> <?xml version="1.0" ?>
>> <Counter>
>> <hits>0</hits>
>> </Counter>

> To manipulate files on the webserver, it'd be better to use a server-
> side scripting language. ActiveX objects only work in IE.
> Personally, I would have a hidden image tag in my document that had a
> url in its src attribute that pointed to a page that read and
> incremented the xml using a server-side language like ASP or PHP.
>
> <IMG style="display:none" src="URL_FOR_COUNTER_PAGE_HERE">

If the objective is to make a simple counter, I think this might be a
good plan indeed. But in that case, I don't see a real need for XML
anyway. Too uneffeicient.

> As for the processing in the counter page, I'd:
> * Read the xml file into a string
> * Search the string for "<hits>" and save the position following the >
> * Search the string for "</hits>" and save the position before the <
> * Get the text between the saved positions and convert it to a number
> * Increment the number
> * Build a new string and write it back to the file

I'm afraid this is the Numero Uno classical design error for such
applications. One should approach XML with the available XML parser,
which typically makes the content accessible by DOM referencing,
binding it to (multidimensional) variables or some other tree-like
structure.

var myXML='<?xml version="1.0"?>';
myXML+="<Counter>";
myXML+="<hits>0</hits>";
myXML+="</Counter>";

if (window.ActiveXObject) {
var doc = new ActiveXObject('Microsoft.XMLDOM');
doc.async = "false";
doc.loadXML(myXML);
}
else {
var parser = new DOMParser();
var doc = parser.parseFromString(myXML, 'text/xml');
}

var hits =
doc.documentElement.childNodes[0].childNodes[0].nodeValue;
// do calculations:
hits = hits * 1;
hits = hits + 1;
// this is the "write back":
doc.documentElement.childNodes[0].childNodes[0].nodeValue = hits;
alert(hits);

The altered content should then be offered (or read out) by ActiveX to
perform the actual save-to-disk action. Being a bit shaky about
ActiveX myself, I would fire a POST request to a script that then
parses the updated XML-file.

--
Bart

Bart wrote:
[snip]
> If the objective is to make a simple counter, I think this might be a
> good plan indeed. But in that case, I don't see a real need for XML
> anyway. Too uneffeicient.

I agree, xml is not needed.

[snip]
> I'm afraid this is the Numero Uno classical design error for such
> applications. One should approach XML with the available XML parser

I agree with you when substantial XML manipulation is needed...
However, for this three-node XML file, I'd rather string parse
than load a big XML library in memory on the server.

I agree with the comments that ASP, firing at either XML, text file,
or ideally a database is the best route for this, however, the brief I
was given was that I was not able to use server side scripting
languages, making the job of a hit counter somewhat tricksy.

I've eventually gone back to the designer and argued into being able
to use ASP. 10 mins later - one simple hit counter.

Thanks for the help though. Appreciate it now looks like wasted
effort on your part...

drink.the.koolaid wrote:

> Bart wrote:
>> I'm afraid this is the Numero Uno classical design error for such
>> applications. One should approach XML with the available XML parser
>
> I agree with you when substantial XML manipulation is needed...
> However, for this three-node XML file, I'd rather string parse
> than load a big XML library in memory on the server.

I agree in this particular case. If the content is under full control
of the author, if there is no other manipulation than increase the
counter, and if the markup can be guaranteed to be fully consistent,
this might be an option. But actually it's then not "real" XML
anymore; it's perhaps better to just load a simple text file with one
number (why would you need the XML for this kind of counter, and why
javascript).

In practice, XML string parsing easily becomes blatantly complex. I
remember my beta-tests of RXParse (Perl) which unsuccessfully tried to
achieve the same goal:

http://groups.google.com/group/comp....b006db41efc7b/

P.S. The XML library would be loaded into the browser in my example,
no need to load anything on the server. Server would only perform the
save-to-disk action, since all XML manipulation was done at the
client.

--
Bart

Kev wrote:
> [snip] the brief I was given was that I was not able to use server side
> scripting languages [snip]

Thanks for the update. Next go 'round, that information would have
been useful in your initial post. Glad you got things working.