X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FSQL%2FTranslator%2FProducer%2FTT%2FTable.pm;h=63b02398f959cb18e33bb3e0e2fc6536ce605a03;hb=478f608d9028508396da37bb5df10b3057b96981;hp=7ff5d5725cc9a53d3186b4aa56f1d34a4e26d75a;hpb=0be5b227cf41450dfbd47a634ace6efdd68b1d24;p=dbsrgits%2FSQL-Translator.git diff --git a/lib/SQL/Translator/Producer/TT/Table.pm b/lib/SQL/Translator/Producer/TT/Table.pm index 7ff5d57..63b0239 100644 --- a/lib/SQL/Translator/Producer/TT/Table.pm +++ b/lib/SQL/Translator/Producer/TT/Table.pm @@ -1,9 +1,9 @@ package SQL::Translator::Producer::TT::Table; # ------------------------------------------------------------------- -# $Id: Table.pm,v 1.1 2004-04-01 19:02:39 grommit Exp $ +# $Id$ # ------------------------------------------------------------------- -# Copyright (C) 2002-4 SQLFairy Authors +# Copyright (C) 2002-2009 SQLFairy Authors # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License as @@ -61,18 +61,19 @@ SQL::Translator::Producer::TT::Table - =head1 DESCRIPTION -Produces schema output using a given Template Tookit template, processing that -template for each table in the schema. Optionally allows you to write the result -for each table to a seperate file. +Produces schema output using a given Template Tookit template, +processing that template for each table in the schema. Optionally +allows you to write the result for each table to a separate file. It needs one additional producer_arg of C which is the file -name of the template to use. This template will be passed a template var of -C, which is the current C table we are -producing, which you can then use to walk the schema via the methods documented -in that module. You also get C as a shortcut to the -C for the table and C, the -C object for this parse in case you want to get access to any -of the options etc set here. +name of the template to use. This template will be passed a template +var of C
, which is the current +L table we are producing, which you +can then use to walk the schema via the methods documented in that +module. You also get L as a shortcut to the +L for the table and C, +the L object for this parse in case you want to get +access to any of the options etc set here. Here's a brief example of what the template could look like: @@ -84,9 +85,9 @@ Here's a brief example of what the template could look like: See F for a more complete example. -You can also set any of the options used to initiallize the Template object by -adding them to your producer_args. See Template Toolkit docs for details of -the options. +You can also set any of the options used to initiallize the Template +object by adding them to your producer_args. See Template Toolkit docs +for details of the options. $translator = SQL::Translator->new( to => 'TT', @@ -97,11 +98,12 @@ the options. }, ); -If you set C and its additional options the producer will write a -seperate file for each table in the schema. This is usefull for producing -things like HTML documentation where every table gets its own page (you could -also use TTSchema producer to add an index page). Its also particulary good -for code generation where you want to produce a class file per table. +If you set C and its additional options the producer will +write a separate file for each table in the schema. This is useful for +producing things like HTML documentation where every table gets its +own page (you could also use TTSchema producer to add an index page). +Its also particulary good for code generation where you want to +produce a class file per table. =head1 OPTIONS @@ -113,10 +115,10 @@ File name of the template to run for each table. =item mk_files -Set to true to output a file for each table in the schema (as well as returning -the whole lot back to the Translalor and hence STDOUT). The file will be named -after the table, with the optional C added and placed in the -directory C. +Set to true to output a file for each table in the schema (as well as +returning the whole lot back to the Translalor and hence STDOUT). The +file will be named after the table, with the optional C +added and placed in the directory C. =item mk_files_ext @@ -124,47 +126,48 @@ Extension (without the dot) to add to the filename when using mk_files. =item mk_files_base = DIR -Dir to build the table files into when using mk_files. Defaults to the current -directory. +Dir to build the table files into when using mk_files. Defaults to the +current directory. =item mk_file_dir -Set true and if the file needs to written to a directory that doesn't exist, -it will be created first. +Set true and if the file needs to written to a directory that doesn't +exist, it will be created first. =item on_exists [Default:replace] -What to do if we are running with mk_files and a file already exists where we -want to write our output. One of "skip", "die", "replace", "insert". -The default is die. +What to do if we are running with mk_files and a file already exists +where we want to write our output. One of "skip", "die", "replace", +"insert". The default is die. -B - Over-write the existing file with the new one, clobbering anything -already there. +B - Over-write the existing file with the new one, clobbering +anything already there. -B - Leave the origional file as it was and don't write the new version -anywhere. +B - Leave the origional file as it was and don't write the new +version anywhere. B - Die with an existing file error. -B - Insert the generated output into the file bewteen a set of special -comments (defined by the following options.) Any code between the comments will -be overwritten (ie the results from a previous produce) but the rest of the file -is left alone (your custom code). -This is particularly usefull for code generation as it allows you to -generate schema derived code and then add your own custom code using it to file. -Then when the scheam changes you just re-produce and insert the new code. +B - Insert the generated output into the file bewteen a set of +special comments (defined by the following options.) Any code between +the comments will be overwritten (ie the results from a previous +produce) but the rest of the file is left alone (your custom code). +This is particularly useful for code generation as it allows you to +generate schema derived code and then add your own custom code +to the file. Then when the schema changes you just re-produce to +insert the new code. =item insert_comment_start -The comment to look for in the file when on_exists is insert. Default is -C. Must appear on it own line, with only whitespace either -side, to be recognised. +The comment to look for in the file when on_exists is C. Default +is C. Must appear on it own line, with only +whitespace either side, to be recognised. =item insert_comment_end -The end comment to look for in the file when on_exists is insert. Default is -C. Must appear on it own line, with only whitespace either -side, to be recognised. +The end comment to look for in the file when on_exists is C. +Default is C. Must appear on it own line, with only +whitespace either side, to be recognised. =back @@ -174,8 +177,7 @@ side, to be recognised. use strict; -use vars qw[ $DEBUG $VERSION @EXPORT_OK ]; -$VERSION = sprintf "%d.%02d", q$Revision: 1.1 $ =~ /(\d+)\.(\d+)/; +use vars qw[ $DEBUG @EXPORT_OK ]; $DEBUG = 0 unless defined $DEBUG; use File::Path; @@ -307,14 +309,14 @@ Mark Addison Egrommit@users.sourceforge.netE. =head1 TODO -+ Some tests for the various on exists options (they have been tested +- Some tests for the various on exists options (they have been tested implicitley through use in a project but need some proper tests). -+ More docs code generation strategies. +- More docs on code generation strategies. -+ Better hooks for filename generation. +- Better hooks for filename generation. -+ Better integration with TTSchema. +- Integrate with L and L. =head1 SEE ALSO