paulb@20 | 1 | See docs/index.html for the libxml2dom documentation.
|
paulb@35 | 2 |
|
paulb@64 | 3 | Testing
|
paulb@64 | 4 | -------
|
paulb@64 | 5 |
|
paulb@64 | 6 | Some of the tests require libxml2macro.py to be run on the test source code
|
paulb@64 | 7 | first. Read the docstrings for the various test files before attempting to run
|
paulb@64 | 8 | any of them.
|
paulb@64 | 9 |
|
paulb@35 | 10 | Issues
|
paulb@35 | 11 | ------
|
paulb@35 | 12 |
|
paulb@35 | 13 | Use of importNode seems to cause some kind of memory issue, probably related
|
paulb@41 | 14 | to nodes being shared across documents. This was observed in libxml2 2.6.0 but
|
paulb@41 | 15 | appears to be fixed in libxml2 2.6.16.
|
paulb@50 | 16 |
|
paulb@78 | 17 | Even compared to minidom, importNode may seem very slow (even the
|
paulb@50 | 18 | libxml2dom.macrolib implementation, too). A way is needed to get libxml2 to do
|
paulb@50 | 19 | the node copying itself.
|
paulb@50 | 20 |
|
paulb@50 | 21 | Experiments
|
paulb@50 | 22 | -----------
|
paulb@50 | 23 |
|
paulb@50 | 24 | The libxml2macro.py program, along with the libxml2dom.macrolib package
|
paulb@50 | 25 | provide support for writing DOM-style code which is then translated to
|
paulb@59 | 26 | libxml2mod-style code before being compiled to normal Python modules. This
|
paulb@50 | 27 | special translation should eliminate the need for high-level wrapper objects
|
paulb@59 | 28 | in most cases as well as low-level libxml2 objects, since the actual compiled
|
paulb@59 | 29 | code will be using the libxml2mod functions directly.
|
paulb@59 | 30 |
|
paulb@59 | 31 | To use libxml2macro.py, first write your code using the typical PyXML DOM
|
paulb@59 | 32 | style, but make sure that you use a common prefix for all node variables and
|
paulb@59 | 33 | which is not used by any other kind of variable, and make sure that you do not
|
paulb@59 | 34 | re-use node variables to refer to other kinds of object. Here is an example of
|
paulb@59 | 35 | the coding style:
|
paulb@59 | 36 |
|
paulb@59 | 37 | # My module.
|
paulb@59 | 38 |
|
paulb@59 | 39 | import libxml2macro as my_
|
paulb@59 | 40 |
|
paulb@59 | 41 | def processing_function(my_document, some_args):
|
paulb@59 | 42 |
|
paulb@59 | 43 | # Perform actions on nodes:
|
paulb@59 | 44 |
|
paulb@59 | 45 | my_node = my_document.createElementNS("namespace", "some-name")
|
paulb@59 | 46 |
|
paulb@59 | 47 | # Perform actions on other data as normal:
|
paulb@59 | 48 |
|
paulb@59 | 49 | some_function(some_args)
|
paulb@59 | 50 |
|
paulb@59 | 51 | Then, run libxml2macro.py on the module like this (using tests/macrotest.py as
|
paulb@59 | 52 | an example):
|
paulb@59 | 53 |
|
paulb@98 | 54 | tools/libxml2macro.py tests/macrotest.py
|
paulb@59 | 55 |
|
paulb@59 | 56 | This produces a compiled module that can be imported into Python; for example:
|
paulb@59 | 57 |
|
paulb@59 | 58 | cd tests
|
paulb@59 | 59 | python
|
paulb@59 | 60 | import macrotest
|
paulb@59 | 61 |
|
paulb@59 | 62 | It should be possible to run the module directly; for example:
|
paulb@59 | 63 |
|
paulb@59 | 64 | python tests/macrotest.pyc
|
paulb@59 | 65 |
|
paulb@59 | 66 | Note that running the module using the source filename will probably result in
|
paulb@59 | 67 | the compiled module being overwritten and various errors being produced. So
|
paulb@59 | 68 | don't do that!
|