I will look more into the DBI trace as that appears to have potential.
I'm surprised nobody has needed this before? I was considering patching the DBI Plugin to save the SQL statements and make them available as part of the exception handling.
Is there a best practice method that I am overlooking? I thought being able to do the simple SELECT queries in TT made it simpler to see what the template what doing and presenting. I had looking at HTML::Template a time or two but I didn't like the seemingly complex way data was passed to the template - the dot notation and direct SQL statements in TT2 are very friendly.
Brian
On 1/8/06, Stuart Johnston <[EMAIL PROTECTED]> wrote:
Although a object-oriented DBI wrapper can make accessing your data from
TT easy and fun, if you are doing just simple, single table selects the
DBI plugin may be a good solution for you.
Either way, the DBI trace function may be helpful to you for debugging.
For example, you can set an environment variable like:
DBI_TRACE=2=/tmp/logfile
See: http://search.cpan.org/~timb/DBI/DBI.pm#TRACING
brian toscano wrote:
> Perrin,
>
> In many of the templates I do a few simple FOREACH r = DBI.query
> (SELECT ....) statements and format the results in table(s) in HTML. Is
> there a better approach that I should consider?
>
> Brian
>
>
>
> On 1/7/06, *Perrin Harkins* < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> wrote:
>
> brian toscano wrote:
> > In mod_perl I had some
> > wrappers around the DBI code and it would tell me the query
> string and
> > the error. It made troubleshooting much easier!
>
> Why did you change it? Doing the DBI work in perl before running the
> template is usually better, and easier to debug as you have seen.
>
> - Perrin
>
>
