[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-dev
Subject:    Re: XmlGen Ant Task
From:       Philippe Collignon <phc () starobject ! com>
Date:       2007-09-20 18:50:30
Message-ID: 46F2C0F6.4080401 () starobject ! com
[Download RAW message or body]

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 library.book[@genre='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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]