On Tue, 12 Sep 2000 10:15:06 +0200, Turbine wrote:
>>I am not too familiar with the way torque works so forgive me if I am
>asking
>>something stupid.
>>My question is:
>>Is there any particular reason not to use XSLT to get SQL, DBMap etc. from
>>XML instead of templates/java code? That seems to be cleaner.
>
>I looked at it, but I needed something that could do some string
>manipulation. Table Names like my_table should become MyTable for java
>code.
AFAIK XSL can do string manipulation just fine.
>The other reason is that I wanted to create java code that is easier to
edit
>and extend. It is more difficult to edit java code that is mingled in xsl
>that to edit a .java template.
I think these stylesheets are not going to be edited frequently, so it
should not be that bad. I think using XSL to convert XML is the right way
because it a _standard_ way to do it. All you need to do is to come up with
the right stylesheet. You don't need to create some home-grown software,
simply use ready to use XML processor which is stable and has a standard to
conform to...
>At some stage I want to move to Velocity. As soon as Velocity reaches a
>point where it is a bit more stable it should be possible to add a new
>grammar that are tailor made for code generation. Hopefully this will ease
>some of the paint of WM in java and especially sql.
Again with XSL you don't have to reinvent the wheel and write a pice of
software which does essentially the same thing as an existing one, hardly in
a better way...
>>Another question:
>>
>>AFAIU, currently Torque is focused on producing file output. I think it
>>would be useful to have it actually _do_ the work: I do not want to carry
>>all the SQL with my distribution, I would prefer to carry single XML and
>>call Torque in the build script to apply the XML directly to the DB. Is
>>there anything wrong with it?
>
>Good idea! Unfortunately I won't have time to look into this. Maybe you
>can have a look at the code and do something along these lines. This is an
>opensource project and newtorque is experimental anyway so feel free to do
>some stuff!
I will probably get round to trying this stuff.
My question here is whether you think that Torque is a good place to do the
work, or it is better to make Torque return it's results in strings and
create another tool which uses these results to do the work?
I also think that same applies to .java files as well. I do not like having
any generated files under source control. Does it make sense to generate the
java sources at the build time and feed them directly to compiler without
creating the files? I understand that you sometimes want to hand-edit the
sources, but I think it's due to Torque having bugs or lacking features, and
it's better to fix the problem where it starts. Once this is fixed
hand-editing will not be needed...
>>Yet another question:
>>
>>Currently there is one XML file per DB. Wouldn't it be nice to have one
>file
>>per table? It would make change tracking more comprehensive and
>potentially
>>enable abovementioned build scripts to be smarter and update changed
>tables
>>only.
>
>You previously said you want to carry a single xml file for your
>distribution, but now you want to split them up :-) (just joking :-).
I was really curious whether anyone is going to notice it... ;-)
In this case this would be a single SET of XML files.. ;-)
>My
>idea was to maybe tell the script which tables to update.
I don't like handing it to the user. If you break file up the detection of
changes is trivial.
>I don't know how
>yet. Maybe some kind of gui that allows you to use checkboxes to choose
>which tables you want updated. Any thoughts on this? Do you feel multiple
>files are better?
I believe so. It will also give you one-to-one correspondense between XML
and java files, so you only need to regenerate java files for the tables
which changed...
Makes more sense?
WBR, Fedor.
_______________________________________________________
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
