in reply to Re^2: On the scaleability of Perl Development Practices
in thread On the scaleability of Perl Development Practices

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.

Oknow
  • Comment on Re^3: On the scaleability of Perl Development Practices

Replies are listed 'Best First'.
Re^4: On the scaleability of Perl Development Practices
by dragonchild (Archbishop) on Aug 19, 2008 at 00:51 UTC
    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.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations