----- Original Message -----
From: "Bob Lee" <[EMAIL PROTECTED]>
> Specifically, I'm just working on some interface extensions.
>
> The current interface is geared towards transforming a directory of XML
> content.
>
> I'm making ant targets for my currrent project that use XSL stylesheets to
> generate code and descriptors for entity beans off of a single XML file.
So you're process runs a single XML file through several XSL
transformations?
You could, alternatively, use <apply> to accomplish this already probably.
It certainly isn't the ideal solution, but thought I'd mention it.
> Combining this functionality into the build script rather than having a
> separate program or script has proven to be clean, convenient, and
> intuitive, and the XSLTProcess task is an integral component, however the
> current interface isn't exactly condusive to this type of application.
There certainly is room for more XML/XSL type functionality, either as
separate tasks or integrated into <style> if suitable.
> Off the subject, do you think XSLTransform would be more accurate and
> intuitive label for this task?
+0 - doesn't matter to me... its mapped to <style> and thats how I see it
mostly. But certainly naming conventions of our tasks needs to be intuitive
and clear. (I think all our tasks should be named *Task.java, at least -
and named close to what its default XML element name is).
By the way, have you given any thought to using Torque/Velocity for your
code generation process? Its already got an XML driven engine, Ant tasks,
and customizable Velocity templates to generate code - and should be easily
tweakable to generate EJB (*ick*) code.
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
