The purpose of this page is not exactly know the answers to the questions asked, but to think about the Catalyst's structure and decisions. Could we make it more clever, less redundant, more easy to use and really follow the K.I.S.S principle stamped on the home page of this site?


For the following questions, suppose your application is called "MyApp?", created using the command: "catalyst.pl MyApp?".

Q1: Why are the template files in "MyApp?/root" (or "templates") and not in "View" directory, which, BTY, only contains the view "engine" file, like "TToolkit.pm".

A1: The "View" directory contains the program logic for view, the templates are just that -- templates and are located with other support or served files...

Comment1: The presentation in a web application is the template files, they contain, if not all, at least most of the programming logic for the "view". Presently, the "View" contains only one file for each kind of presentation the application uses, for example one for HTML output and one for PDF output.

Comment2: No, if you use TT or some other view type that allows coding inside you do get some of the view in there, but the templates are not the presentation -- one of the strongest reasons to play out web development this way is to not do what you are asking. The designers should be able to design and write html, the app should present the html or pdf whatever.


Q2: Why aren't directories "Model", "View" and "Controller" written only with lower case letters ?

A2: Why is MyApp written with caps? how about "use Module::Name::Blah" -- it is how things are done in perl.

Commnet2: see Comment3


Q3: Why directory "lib" does not have a more meaningful name like "application", "app", "src".

A3: Catalyst applications are structured like normal Perl modules. Learn how to write Perl modules and everything will make sense (some hints: google for h2xs, search for "Writing Perl modules for CPAN", by Sam Tregar).

Comment3: This is the expected answer to this question. The real question here is whether Catalyst should follow exactly that structure, since we are talking about applications that have a meaning by itself, not necessarily modules made for only to be reused. If Catalyst were is free from the obligation to look like a regular Perl module, it could have a cleaner structure.

Comment 4: using Perl's module structure is IMHO a Good Thing, because 1) we are developing Perl applications using a Perl framework, i.e. we are in a Perl world (as long as Catalyst is concerned, of course), therefore one would expect things to be consistent with the Perl style; 2) Perl's module structure is known to everyone who has written even the simplest Perl module; 3) Perl's module structure has proven to be a good foundation for Catalyst application (IMHO); 4) it's not wise to reinvent the wheel for every major project unless there is a clear need to do so, and I don't see any such need for Catalyst applications.


Q4: Why does "lib" exist at all? Why aren't "MyApp.pm" and directories "Model", "View" and "Controller" located in the application root directory ("MyApp?") ?

A4: see previous answer.

Comment4: see Comment3


Q5: Why not really adopt the DRY (Don't Repeat Yourself) principle? Is DBIx::Class and/or Class::DBI to blame ?

A5: DBIx::Class already does - you can use DBIx::Class::Schema::Loader to load table, column and relationship information off the database or $schema->deploy to setup the database schema from your perl classes. Either way, you only have to specify things once. If you'd like to discuss this further, please raise the question on the dbix-class mailing list since this is not really a Catalyst issue.

Will the author of this question please explain what s/he really mean ?

Comment 1: May be the author means not duplicating in code what is said as metadata in the DB ? If so, the answer is that such an ORM unfortunately still does not exist.

Comment 2: Class::DBI and DBIx::Class both have some sort of ::Loader plugin that do exactly what the presentation you mentioned says an ORM should do. Of course we're far from perfection, but we're also far from the need to retype all your DB metadata in Perl.

Also, this has nothing to do with Catalyst per se.