paulb@79 | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
paulb@79 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"> |
paulb@79 | 3 | <head> |
paulb@79 | 4 | <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> |
paulb@79 | 5 | <title>libxml2macro</title> |
paulb@79 | 6 | <meta name="generator" |
paulb@79 | 7 | content="amaya 8.1a, see http://www.w3.org/Amaya/"> |
paulb@79 | 8 | <link href="styles.css" rel="stylesheet" type="text/css"> |
paulb@79 | 9 | </head> |
paulb@79 | 10 | <body> |
paulb@79 | 11 | <h1>libxml2macro</h1> |
paulb@79 | 12 | <p>The libxml2macro tool and accompanying libraries (<code>libxml2dom.macrolib</code>) |
paulb@79 | 13 | provide and experimental mechanism for writing normal DOM-style code |
paulb@79 | 14 | (with node objects) and being able to transform such code into direct |
paulb@79 | 15 | calls and accesses to the low-level libxml2mod API. Since libxml2dom |
paulb@79 | 16 | now makes use of these libraries, and since the objects created at the |
paulb@79 | 17 | libxml2dom level do not necessarily introduce a huge time or memory |
paulb@79 | 18 | overhead, this mechanism is now more an experimental curiosity than |
paulb@79 | 19 | anything of practical use. Moreover, the generated code does not |
paulb@79 | 20 | attempt to clean up after libxml2, potentially introducing memory leaks |
paulb@79 | 21 | into programs.</p> |
paulb@79 | 22 | <h2>Using libxml2macro</h2> |
paulb@79 | 23 | <p>The libxml2macro approach is as follows:</p> |
paulb@79 | 24 | <ul> |
paulb@79 | 25 | <li>Write code using the PyXML-inspired DOM-style API, but giving |
paulb@79 | 26 | node variables and attributes a distinct prefix.</li> |
paulb@79 | 27 | <li>Run the supplied tool <code>libxml2macro.py</code> on the source |
paulb@79 | 28 | file.</li> |
paulb@79 | 29 | <li>Invoke the compiled module directly or import it into programs as |
paulb@79 | 30 | usual.</li> |
paulb@79 | 31 | </ul> |
paulb@79 | 32 | <p>A description of the process is given in the <code>README.txt</code> |
paulb@79 | 33 | file |
paulb@79 | 34 | within the source code distribution. However, what libxml2macro does is |
paulb@79 | 35 | to |
paulb@79 | 36 | take code like this...</p> |
paulb@79 | 37 | <pre>for my_node in my_element.childNodes:<br> if my_node.nodeType == TEXT_NODE:<br> print my_node.nodeValue</pre> |
paulb@79 | 38 | <p>...and to transform it into something more or less like this |
paulb@79 | 39 | (although in |
paulb@79 | 40 | practice the actual libxml2mod calls are provided in a library, |
paulb@79 | 41 | although more |
paulb@79 | 42 | aggressive transformations could result in something actually like |
paulb@79 | 43 | this):</p> |
paulb@79 | 44 | <pre>for my_node in libxml2mod.children(my_element):<br> if libxml2mod.type(my_node) == "text":<br> print libxml2mod.xmlNodeGetContent(my_node)</pre> |
paulb@79 | 45 | <p>The result is that developers can still write DOM-style code but not |
paulb@79 | 46 | be |
paulb@79 | 47 | penalised for the object-related overhead that such an approach |
paulb@79 | 48 | typically |
paulb@79 | 49 | incurs.</p> |
paulb@79 | 50 | </body> |
paulb@79 | 51 | </html> |