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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
