Nathan Bubna wrote:
The documentation for this looks great! How does this compare to
other xml-generation/transformation Velocity projects (namely DVSL and
Anakia). Not that there isn't room for more, there always is; i'm
just curious how you think it compares.
Here is how I would compare them. ( I do not know the other
implementations in details
so if I forget some features just tell me ..)
About Process :
-----------
Anakia
One XML + One Velocity Template (vsl) => Generated Code
It is designed to create XML transformations a bit like XSLT
DVSL
One Velocity Template (dvsl) applied to a set of XML files => Generated Code
It is designed to create XML transformations a bit like XSLT
Texen
text property files + velocity template => Generated Code
XmlGen
Multiple XML files (or file fragments with XPath) + velocity template =>
Generated Code
Extension of Texen. It is more designed to generate code with
properties coming from XML files than XML files transformations.
About XML Nodes access :
-------------------
Anakia :
Using jdom API ( element.getChildren(), element.getAttributeValue("attName"))
Using xpath with velocity handler (I suppose) :
$xpath.applyTo("expression",node)
Walking in the jdom tree with : $treeWalk.allElements($element
DVSL
Write transformation rules like in XSLT
(#match("document") , $context.applyTemplates()
Using dom4j API
Texen
No access to XML files, only property files supported
XmlGen
Using syntax like "library.books" of "book.name"
Using XPath expression [EMAIL PROTECTED]'comic']
Using DOM API on elements
If it's a large codebase or is intended to be a separate project (as
opposed to an enhancement to an existing project), then it would have
to go through the incubator:
http://apache.org/foundation/how-it-works.html#incubator
It does a good job but is not really a large codebase ...just 3 classes !-)
If it could be refactored to be just a patch(es) to enhance Texen,
then i think you would just need to open a JIRA issue and attach the
files there. Of course, then there's the question of eventually
getting you commit access so that you can work on it directly, so we
don't always have to commit your patches for you. For that to happen,
we'd want to see evidence that you'll stick around (not just dump code
once and disappear) and help out on the mailing lists. So, more than
anything it's a matter of seeing comittment over time (we're talking
months, not weeks). The reason for the high standard is that
abandoned code becomes a weight on the rest of the project(s) and that
commit access to one Velocity project means access to all of them.
That might be possible. Not only Texen code would have to be patched
but also the documentation.
XmlGen is at the beginning, for now it fits my needs but I am sure they
might be some other
feature requests .. I am ready to make it improved and give some
support. Regularly but not
more than 1h a week.
In any case, you should definitely announce your project on these
lists (as you've done), add some links to it on the wiki (like the
PoweredBy page and anywhere else that seems relevant), and generally
promote connection between XmlGen and Velocity.
I go there a leave a word about it !
Thanks for your answer
Philippe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
