XCG is a command line utility for transforming the structure of an XML instance
into some kind of structure. It was created to help me generate wrappers for
several dozen different XML formats that I was working with. As a result of the
need, the first version generated c++ code wrappers around libxml2, which after
a lot of research appeared to be the best solution for my XML reading and
Now, it is much more powerful than that what I just described. Instead of just
generating c++ wrapper code, it now generates based on the contents of its
configuration, which is contained within XML. In fact, it uses itself to
generate the code to read the XML configuration file (well, not directly, but
its the same end result). It could be self hosting simply by embedding a copy
of the default XML configuration in the executable; I chose to keep it external
to make it easier for others to modify the default code generation.
I suppose I should explain why I didn't use a DTD or schema as the basis of the
generation. Problem is, I don't really have what I consider solid reasons. For
most of the XML data I was involved with, there either wasn't a DTD or schema,
or if there was, it was out of date. I suppose I could have made the creation
and/or update of the DTD's or schema a requirement, but in the end, I found
myself creating a lot of last minute simple XML instances with all kinds of
short little formats for things that would never be used again (look at
example3 for a real world example). Yes, I could have used XSL to do
some/most of these translations and such. However, in the end, I think what
made me choose this method was a library named
TinyXML that has a pretty faithful following because it is so easy
to use (alas, it has a few issues that make it unusable for me). I also wanted
something that was as easy to use, but which would be much more flexible. This
is where I ended up, and I am actually very happy with the
result! If one is familiar with stl, then the default code generation is pretty
straight forward to use; Because all elements are wrapped in objects, and those
objects don't allow direct acess to any data, it actually is highly
maintainable as well. As always, there are a few things I still want from it,
but its a great start.
As a result of using a configuration file (called a "template"),
there are very few limitations on what XCG can generate. So far, the
limitations I have encounterd are more annoyances than limitations; Issues I
got around by making significant modifications to my template - but which a few
extra featuures will eventually make much easier to deal with.
The following is a list of the major features (or functionality) provided by
XCG in its current form:
Output is completely configuration defined: There isn't a requirement to output
source code - it can literally be anything desired!
Any number of files can be generated, as all generated files are defined by the
template. For example, if 1 class per element is created, one can have each
class in a seperate file, or one can have all of them in a single file (like
the default generation)
Unlimited iterations through elements, both at file and sub-file scope (i.e.
one could iterate over elements, and within the generated text of that
iteration, iterate over them again, recursively). Depth is limited by machine
hardware, not XCG itself (just don't forget to make it end somewhere!)
Unlimited iterations of children of an element within an element iteration
(without an element, how can there be child elements?)
Unlimited iteration of attributes of an element within an element iteration
(without an element, what are attributes?)
One can reference the name of the current file, element, attribute, child
element, or the root element within the generated text.
In addition to the previous item, there are some built in transformations that
can be done on the file, element, attribute, child element and root elements
Capitalize first letter
Capitalize entire name
Perform name replacements (for example, replacing words reserved within the
Replace invalid characters with valid characters (or strings)
Remove invalid characters and capitalize next char (for example, make
"foo-bar" into "fooBar")
For pluralization, the template can provide verbatim pluralized forms of words.
For example, pluralizing "child" isn't just a matter of adding an
"s", so one could provide a pluralized form of child as
A list of invalid characters, and their replacements can be specified in the
A list of invalid words, and their replacements can be specified in the
Eventually, all transformation lists will be able to specify their context. For
example, maybe a word replacement is only valid while iterating through
Isolates your XML file i/o from the underlying technology. If you later on
decide to change the technology of your XML support, its simply a matter of
updating the template to generate the exact same external interface, but
internally use the new technology. For example, currently the default
generation is for libxml2. However, if I decided to change to using the Apache
XML OpenSource library, I can modify the template to use a different back end
(the Apache XML library), but keep the external interface the same. Its then
simply a matter of a recompile to change the back-end technology from libxml2
to Apache XML!
Abilities available in 1.1.0 or later
<element> allows user defined meta data.
Template and element specific information are now contained in seperate files.
This makes it easy to use the same template code for multiple projects, as the
data that is specific to a project is in a seperate file. For example, all
<template> elements are contained within a template file, but the new
<element> elements are only in the configuration file. Additionally, the
<replacement>, <invalid>, and <plural> elements can exist
in either or both files.
<condition> elements allow custom conditionals. All standard conditions can be used
as well as the values of the new meta data can be queried.