No argument from me. Feel free to propose a branch that does the things you describe below. I'm sure you'll get feedback in code review :)
Cheers! -jay On Tue, Jan 3, 2012 at 2:17 PM, Joshua Harlow <harlo...@yahoo-inc.com> wrote: > 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: > > 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?) > > 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) > 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). > Write output created by formatter class to domain.xml file (and continue as > normal). > Profit! > > > Some of the benefits I think exist with this: > > XML escaping will actually happen (does this happen right now?) > 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) > 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). > 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). > 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). > Possible remove a dependency (always good). > > > Thoughts? > > -Josh > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp