The reason that Class::DBI and the Template Toolkit work so well together is simple. Template Toolkit templates can call methods on objects passed to them--so there's no need to explicitly pull every column out of the database before you process the template--and Class::DBI saves you the bother of writing methods to retrieve database columns. You're essentially going straight from the database to HTML with only a very small amount of Perl in the middle.
retrieve_all
is actually a package method but there's not much to prevent the object from calling it too.) All this with the both theEVAL_PERL
andLOAD_PERL
config flags explictly set to false. You can get around this, sort of, if your object doesn't have any circular relationships (e.g.A->has_a(B->has_many(A))
) by adding a method that sets a trigger to die before an object is updated or deleted. But there isn't really any way to cascade setting those triggers so there is always the possibility of mucking with the original object in a round-about fashion: I've spent a little bit of time investigating (1, 2) how to make cascading readonly objects but it's still an ugly hack that requires mucking with private functions in Class::DBI. The proper thing to do would be to abstract all of this stuff into a CDBI::ReadOnly package but that might be a while in coming yet. Know you know. via paranoidfish