No worries, Ajith - I think it's generally more useful to look at the actual documents than the schemas, anyway.

 - Dennis

Ajith Ranabahu wrote:

Hi Dennis,
Not publishing the schema's for the codegen  XML's is my fault
actually. Since things were modified rapidly in the first stages, I
wanted to wait until things are stable. But it slipped my mind.
I'll add the necessary schema's soon.

Ajith

On 3/30/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
Chuck Williams wrote:

"Ajith Ranabahu" <[EMAIL PROTECTED]> wrote on 03/29/2006
07:37:48 AM:

I'm not familiar with the velocity or freemarker template languages
but In any case I guess we'll be introducing another dependancy! Also
if  we special case the templating language, it makes things harder
for the people who would need to tweak the code generator.


As someone who's tweaked the code generator to add support for choice
particles, recursive data types, etc., I'd like to second Ajith's
point.  Xsl is a broadly known syntax that works well for the
generation of final Java code.  Having the code generator structured
as it is now, creating a POJO representation of the schema,
transforming that into a DOM, and then using xsl to transform the DOM
into Java classes, is clean, easy to understand, and quite flexible.
I'm somewhat less thrilled by the use of XSLT for code generation, but
passing data in XML is certainly a plus. Overall I found the code
generation structure very flexible and easy to extend. I didn't find any
documentation of the actual XML formats, though, so I added debug
logging of the XML documents used for code generation in
MultiLanguageClientEmitter to simplify understanding the existing XSLTs.

 - Dennis



--
Ajith Ranabahu

Reply via email to