openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

I was wondering if there has been any thought or consideration of removing tempita and replacing it with "just python".
Personally the current tempita usage (libvirt.xml.template) seems to be heading down a hairy path and I wanted to see others opinions on say replacing this with something that doesn't require a whole templating language to use. Some of this may just be my bias against templating languages from experience in different projects @ yahoo (they always start to get hairy, especially when u start to code in them).

Some thoughts:


 1.  Assuming we can get a libvirt.domain.xsd (?) we can use a xsd->object model utility to transform that xsd into a python object model (there seem to be a couple of these?)
    *   http://www.rexx.com/~dkuhlman/generateDS.html or http://pyxsd.org/ (or something else?)
 2.  Create a exposed "tree" representation of the sections of the libvirt domain xml that we are interested in (and only those that we are interested in) as python objects and have current code create these objects (which right now is basically a set of python hashes getting sent to the tempita library)
 3.  Pass the root element of this exposed "tree" representation to a formatter class (which itself could use pyxsd objects, or tempita - for backward compatibility, or something else, but I have a strong preference for keeping a single language in use, instead of a tempita language and a python language).
 4.  Write output created by formatter class to domain.xml file (and continue as normal).
 5.  Profit!

Some of the benefits I think exist with this:


 1.  XML escaping will actually happen (does this happen right now?)
 2.  We can have a underlying object layer which comes directly from the libvirt.domain.xsd (and possibly have versions of this to work with different libvirt versions)
 3.  We can have an exposed object layer which will attempt to be version independent of the underlying layer and only contain methods/properties that we will use with libvirt (ie the xsd will have many properties/fields we will not use, thus we should not expose them).
 4.  We can have a formatter layer that will know how to use this exposed layer and return a object that can convert the exposed layer into a string, thus allowing for different implementations (or at least a separation of what is exposed, how its formatted and what the formatter internally uses).
 5.  We can have the if statements and loops and such that are starting to get put in the template code in python code (thus u don't have to context switch into a templating language to make changes, thus making it easier to work with libvirt).
 6.  Possible remove a dependency (always good).

Thoughts?

-Josh