> >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.
I need to take out all the _ and make sure there is a capital letter where
the _ used to be and then make sure everything else is lowercase. This is
easier to do in java.
> >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...
I've yet to see the schema I generate without doing at least some minor
changes to the templates. There is already talk of some new functionality
that is needed to handle joins and so forth.
It is also much easier to edit code that is template based that to reverse
engineer something to create a stylesheet from.
> >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
I'm not. I'm using a standard of the shelf template engine.
>and write a pice of
> software which does essentially the same thing as an existing one, hardly
in
> a better way...
>
> >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...
I _always_ hand-edit my Peer code after it has been generated.
> >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?
>
Definitely something I'll look into.
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
