Consider the following sample samp.xml file:
/*
< xml>
< station>
< id>aacc< /id>
< lat>33.124< /lat>
< long>110.223< /long>
< station>
< id>bbcc< /id>
< lat>32.124< /lat>
< long>110.289< /long>
< /station>
< /xml>
*/
We can use java codes to analyze the xml files in jsp, e.g., with SAXReader. But when mixed with javascripts, this will generate ugly html source codes. For instance, if there are hundreds of stations in this xml, and we wanna create one google map marker for every station, we might write the following codes in jsp:
/*
< % for (int i=0; i < count_station; i++) { % >
marker[idx++] = new GMarker('<%=station.element("id").getText()%>', ...);
< % } % >
*/
And this will result in hundreds of lines like "marker[idx++] = new GMarker('aacc', ...);" in the html generated from this jsp. On the other hand, if we can manipulate xml files directly with javascript, codes will be much more elegant. To be honest, I always think jsp is ugly. If we really want the web interface to do more things, we'd better come back to the time of ActiveX object of applications, where codes of the objects are compiled and execute much faster...
To avoid such ugly codes, we can manipulate xml files just in javascript. The specific object to use depends on the type of browser:
function xmlMicoxLoader(url){
//by Micox: micoxjcg@yahoo.com.br.
//http://elmicoxcodes.blogspot.com
if(window.XMLHttpRequest){
var Loader = new XMLHttpRequest();
//assyncronous mode to load before the 'return' line
Loader.open("GET", url ,false);
Loader.send(null);
return Loader.responseXML;
}else if(window.ActiveXObject){
var Loader = new ActiveXObject("Msxml2.DOMDocument.3.0");
//assyncronous mode to load before the 'return' line
Loader.async = false;
Loader.load(url);
return Loader;
}
}
var changeXml = xmlMicoxLoader("/samp.xml");
var xmlNode = changeXml.childNodes[0];
Then we can treat this xmlNode as the root node of a tree structure corresponding to the structure of the xml elements, and reference the elements at different layers from different layer of child nodes:
for (var i=2; i < xmlChildCount; i++, saIdx++) {
stationNode = xmlNode.childNodes[i];
var id = stationNode.childNodes[0].firstChild.nodeValue;
....
}
Note that for pretty-formatted xml files, the dented tabs, spaces and line-changes are treated as a special kind of "text" nodes--in fact, even in "ugly-formatted" xml files where no spaces or line-changes we still find these "text" nodes--so unless we are very sure about the layout order of "text" nodes and xml-element nodes that are really useful for us, we should always check the type of nodes before access their child nodes, or node values. For example, for traversing the whole tree structure:
function xmlMicoxTree(xmlNode,ident){
//by Micox: micoxjcg@yahoo.com.br
var treeTxt=""; //var to content temp
for(var i=0;i < xmlNode.childNodes.length;i++){//each child node
if(xmlNode.childNodes[i].nodeType == 1){//no white spaces
//node name
treeTxt = treeTxt + ident + xmlNode.childNodes[i].nodeName + ": "
if(xmlNode.childNodes[i].childNodes.length==0){
//no children. Get nodeValue
treeTxt = treeTxt + xmlNode.childNodes[i].nodeValue
for(var z=0;z < xmlNode.childNodes[i].attributes.length;z++){
var atrib = xmlNode.childNodes[i].attributes[z];
treeTxt = treeTxt + " (" + atrib.nodeName + " = " + atrib.nodeValue + ")";
}
treeTxt = treeTxt + "
\n";
}else if(xmlNode.childNodes[i].childNodes.length>0){
//children. get first child
treeTxt = treeTxt + xmlNode.childNodes[i].firstChild.nodeValue;
for(var z=0;z < xmlNode.childNodes[i].attributes.length;z++){
var atrib = xmlNode.childNodes[i].attributes[z];
treeTxt = treeTxt + " (" + atrib.nodeName + " = " + atrib.nodeValue + ")";
}
//recursive to child of children
treeTxt = treeTxt + "
\n" + xmlMicoxTree(xmlNode.childNodes[i],ident + "> > ");
}
}
}
return treeTxt;
}
Except for the problem of "text" nodes, performance is also an important drawback of using javascript to manipulate xml files, especially when the file is large and there is a big number of nodes to process. For example, when employed for analyzing the result xml file of daily rdahmm, because there are too many stations to process, the loading time of the page becomes unacceptable. As a result we came back to the java code solution, which is much faster, but produces ugly codes, and results in a large html file. The loading time mainly depends on the execution of jsp codes when the network connectivity is good, which is the normal case, so this makes the portlet response more quickly.
Wednesday, January 2, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment