On Thursday, July 26, 2001, at 09:57 PM, Michael Gerdau wrote:
>> my main worry about your proposal is that it's (stated) aim is (near
>> enough) to duplicate torque.
>
> If I'd known torque when I started writing my stuff I probably would
> not have done it.
>
> Now with knowing there is something like torque I'm not too eager to
> continue "my" (i.e. Nick's and my :) work. In fact I'd only want that
> if I'd get the impression torque does have "unfixeable deficiencies"
> which for the time being I don't think it does.
>
>> why replace xslt with texen?
>
> Oh, I personally don't like xslt in the first place. I'm coming from
> using perl for this type of task. In comparison xslt is crude and
> cumbersome (trying to be polite ;)
>
> The only reason for me to _not_ suggest perl for this type of task
> (and indeed I do have written perl scripts that generate C++ code as
> vital parts of commercial projects) is that I'm under the impression
> that many developer in the Java/jsp-world dislike (if not "hate") perl
> and I'd rather work in an environment where major parts of the job
> are or will be done by others :-)
>
>> there are many reasons but one good reason is that velocity templates are
>> *much* simpler.
>
> The examples seem to proove that point and that's what initially caught
> my interest.
>
>> for example, here's a template that does something similar to your entity
>> example (i'll not include the entity.xsl since it's a little long ;-).
> (...and contains some minor bugs ;)
> [code skipped]
>
> This code snipped as well as the examples I've seen immediately
> reminded me of perl - my first impression was that the designers of
> this language had "stolen" from perl (nothing wrong with that :-)
i don't think that gier would use the word 'stolen' more 'learned from' :)
> And I agree: this definitely is much simpler.
>
>> if you're project was about generating neat and useful source code from
>> xml then i'd agree.
>> the stated aim of your project seems (to me) something different.
>
> "generating neat and useful source code from xml" certainly is an issue.
>
> Maybe I should relate what made me starting it in the first place
> (Nick might have different motives).
>
> As I already wrote I do use perl for generating data access classes
> in C++ (for a long time now). This works just nicely and is (mostly)
> RDBMS-independent.
>
> When I started using Java, JSP and struts for writing webapps I quickly
> missed these data access classes. The proposed xslt stylesheets do
> solve most of the immediate issues (and I use them - newer versions i.e.)
> .
>
> However I realized that many repeated tasks involved with writing form
> based applications (be it webapps, traditional GUI stuff or whatever),
> do result in ever repeating code generation stuff. That's why there are
> so many form based code generators.
>
> Unfortunately many, most or all of these are vendor/language/platform
> specific and indeed do employ their own set of acompanying class
> libraries.
> Usually that makes them of little use in open environments.
>
> So I decided to start "rolling my own".
>
> Not knowing a better tool I fell for the xslt (hype). I'm not sure I
> will remain on that road. So far torque seems a better alternative.
sorry if i came down a bit strong.
i understand a bit better know. i sometimes use texen to generate some
stuff like that - but a library of good templates with good documentation
would be excellent :)
your proposal states
"The goal of this package is to provide a framework for
defining and automatically generating Beans used to encapsulate data
retrieved from a database, and the corresponding JDBC access code.
The input to the code generation (datamodel definition) is an XML
configuration file that is translated via XSLT."
i'd like to see this modified so it talks about a library (of templates?)
rather than a framework. that way it's clear that you don't want to start
a war with torque.
> If only I could find more time...
i can probably port the datamodel proposal code to use texen rather than
XSLT pretty quickly if that's any use.
- robert
