Thanks for the comments!

Was it necessary to write one? Does it offer anything not found in HTML::Template or HTML::Seamstress?

No, of course not. However this is based on code that I have been working with for several years, and that I am familiar with. We used this sort of thing at eCircles - actually this is an evolution of the framework we had at eCircles.

I believe I mention that other templating systems exist, and that they may in fact be better than the one I used here (and if I didn't mention it in the slides I know I talked about this during the presentation).

To respond to your other points:

• by data integrity I mean that any DML that needs to be run in a transaction (i.e. where more than one operation needs to be performed) are wrapped in a single stored procedure. This guarantees that the entire operation happens correctly, and also that a client that is hung doesn't hold up transaction flow on the server.
• Personally I'm not really keen on things like DBIx::Recordset. Where access to the database is concerned I do not want things to automatically mutate when the database changes. I want the changes to be done in a controlled manner: the database schema shouldn't change that often (OK, so real life is sometimes not so clean...) and making the changes in the stored procs should be part of the changes done to the database
• As for using more memory on the server - I don't believe so. The code presented here is 100% specific to Sybase database servers. It is my contention that having a large number of prepared statements (i.e. statements with placeholders) will use at least as much memory as the stored procs (actually I have had discussions with a Sybase technical consultant who mentioned running out of procedure cache on the server when using a lot of prepared statements with placeholders).
  In addition preparing multiple such statements in advance (with DBI and DBD::Sybase) will require each http child to have one database connection open per prepared statement - not a good thing.

How would you handle different passwords for production and dev environments?

The passwords are stored in the conpool.cfg file and are used by the Sybase::Apache::ConPool module directly. My solution differs from DBIx::Connect because I use my connection pooling module to share a few database connections between all the apache processes on the machine.
Again I should emphasize that this is a Sybase specific solution, hence it does not use things like DBI at all.

Michael