Hi,
> The database mapping stuff will be tested today and tomorrow by me. I will
> post lots of comments on it i'm sure. I think that Torque is the right
> direction for doing all of the autogeneration of stuff. Whatever Leon has
> done that is missing from Torque should be integrated into Torque and we
> should remove all the stuff that is in the tools directory that duplicates
> Torque functionality.
I've been trying to get ideas to make generation of code files easier in Torque.
I wanted to check it out with Jason first because it sounded if he might be
working on something similar at the moment, but his private e-mail keeps bouncing
:-(
Basically the idea is to make the file generation more generic. This would allow
anyone to maybe tweak his generated Peer classes or even generate a new set of
source files all together! I envision that in (the near :-) future we will have a
collection of these "generation sources" that generates anything from peer classes
to screens and actions.
I would really like some input in this regard be cause I feel strongly that if we
do a decent job on this we will add an enormous amount of value to Turbine. High
quality tools are the only way we can rival Microsoft's new .net initiatives.
www.microsoft.net
At the moment I see two possible ways of doing things. Please give it some
thought - I tend to prefer the second.
First is an .xml generation file that might look something like this.:
<app>
<declaration>
<!-- specify which db to use & set some global variables -->
</declaration>
<generation>
<!-- everything between this tag gets repeated for each table -->
<tables>
<!-- creates a new file with the table name -->
<newfile name="$table.name.upper">
<!-- writes a line to the file -->
<line>import org.apache.turbine.*</line>
<!-- loop through table columns -->
<columns primary="0" foreign="1">
<!-- write each foreign key column name to the file -->
<line>$column.name.lower</line>
</columns>
</tables>
</generation>
</app>
This file takes a DatabaseMap (recieved from *SchemaToDatabaseMap) and allows you
to specify what the generated file should look like. You can loop through all
tables and columns to generate your file.
Another idea - which Frank pointed out to me - is that we could drop the idea of
an .xml file and use a WebMacro template. I tend to lean more towards this idea
because it has some advantages.
A big advantage of this is that you could write a .java file and just replace the
places where table/column names should be with WebMacro. You can even create a
.java file and check if it compiles an then only replace the necessary lines with
WM. Another advantage is that WebMacro already provides a very flexible
architecture - why re-invent the wheel? It would also be hard to generate xml
output with an xml generation file but would be easy with WM. Last but not least
WM files could be broken up into more logical units (see example below) which
would be more difficult to do with xml.
WebMacro might work something like this:
generator.wm:
#set $data = $dababase.loadShema()
#foreach $table in $data.tables
#begin
// table, soure, destination
$generateUtil.parse ($table,"peer.wm",$table;Peer.java)
$generateUtil.parse ($table,"mapbulder.wm",$table;Map.java)
// etc...
#end
peer.wm:
import org.apache.turbine.*;
class $table Peer
{
#foreach $col in $table.Columns
#begin
$col.name
#end
}
Of course these are incomplete examples to build Peer classes, but it can be
equally useful to generate any class (or .sql or .xml or whatever). Jason's .sql
generator and the *OMGenerator classes will the eventually be replaced by
generation .wm or .xml files. Especially with the .wm generator it will be easy
to say for example generate .html forms and insert/update code:
html.wm:
<form>
<input type="hidden" name="id" value="$table.getPrimaryKey">
#foreach $col in $table.Columns
#begin
$col.label
<input type = "text" name="$col.name" value="$col.defaultValue">
#end
<input type="submit" value="OK">
</form>
I think that the input should start out as a DatabaseMap to get something going as
soon as possible and to be backwards compatible, but will be better to extend
Jason's xml schema to include more information and create another (based on
DatabaseMap) java representation in order to have more information to generate
advanced screen/action code.
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
