Re^2: On the scaleability of Perl Development Practices

[dragonchild]

You want a tutorial on how to "write a web application using <DB Abstraction Module>, <Templating System>, and <Runtime Backend>." There are likely a half dozen reasonable choices for the first two, and three or four choices for the backend.

I am not sure I understand why you need a tutorial explaining how to use three systems in concert when they are all so well isolated.

Ah, but they aren't. For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp. Or, using Text::Template and Rose::DB with Mason. And so on. While you can mix'n'match, there are some that work better with each other than with others. Hence, the usefulness of the requested documentation.

[talexb]

For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp.

I disagree -- the module CGI::Application::Plugin::TT ties Template Toolkit and CGI::Application together very nicely, and you can see piles of plugins for CGI::Application if you do a CPAN search on 'CGI::Application::Plugin'. I used CGI::Application::Plugin::Session, CGI::Application::Plugin::DBH and CGI::Application::Plugin::Stream in a recent web application. I'm a fan.

[perrin]

the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp

I don't actually see much integration between Catalyst and TT or DBIC. It's not really possible when you take a hard line on being able to switch components. Jifty is the only really integrated perl dev framework I can think of.

[oknow]

Ah, but they aren't. For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp. Or, using Text::Template and Rose::DB with Mason. And so on. While you can mix'n'match, there are some that work better with each other than with others. Hence, the usefulness of the requested documentation.

I suppose I should remember that it is rarely safe to speak in absolutes. The modules that play better with certain modules than others state that pretty clearly in their documentation, don't they?

Modules that don't play well with others are far less common than those that do.

[dragonchild]

I've found it to be pretty rare for modules to say which work better with whom. For example, even though Catalyst and DBIx::Class were practically designed to work together (given that mst is the primary dev on both), there's little in the documentation of either that states that. Same with the fact that TT tends to be the templating system of choice for that sort of system.

Modules that don't play well with others are actually the rule. A given module will only work well with those systems that the author(s) know well. For example, Excel::Template needs to have a wrapper in order to work with Template Toolkit, even though I worked with TT before writing E::T. DBM::Deep doesn't work at all with objects that have $dbh's in them, even though I'm also a DBA. It's hard to write completely general-purpose code.