Re: Re: Why CGI::Application?

[dragonchild]

A few answers. Let's say you have a reasonably complex application. Let's say you have, oh, 100 unique pages. That's right about middle-sized (in my experience). Let's say they're broken up in 4-7 different functional areas, with some overlap (searching functionality, etc), but each has different needs (different shared functions, validators, etc).

Now, there's a number of different architectures one can do. I'm going to assume you're using templates and an RDBMS (like MySQL or Oracle). I'm also going to assume you're using intelligent developer practices, such as design, documentation, and testing.

1. Monolithic: One script. Period.
   I hope I don't have to tell you why this is bad. Maintenance, performance ... it all suffers.
2. Communist: One script is one unique page. They all live in the same cgi-bin directory.
   I don't know about you, but I'm going to run out of ways to name my scripts. Also, I'm going to want a way of saying "This script and that script are related" in the filename.
3. Clannish: One script is one unique page. Each functional area has its own sub-directory.
   So, now we have a "Reports" and a "Preferences" and a "Admin" area. Each script is still named uniquely, but they're now named relative to their directory.

   (In all the "One script, One page" options, you also have the fact that you have a bunch of other files running around, attempting to link everything together. This is the shared code, from "How do I get a $dbh" to "How do I print" to "How do I log an error". This is maintained separately.)

4. Socialist: One script is one functional area.
   Now, you're developing similarly to C::A. Except, you're doing everything C::A does for you. By hand. In multiple places. Most likely with if-elsif-else. You probably have a bunch of objects you create to do the heavy lifting. They either inherit or delegate to other objects which answer the shared code questions.
5. CGI::Application: One script is the entry point to one functional area. C::A does the heavy lifting.
   Now, you're cooking with gas! You have one class that has your app-wide stuff. Each functional area has one class which contains the uniqueness of that area. Each page view has a run-mode, as well as each page action. You don't worry about how stuff is connected - you just play with the TinkerToys(tm).

I would consider that an evolutionary scale. C::A does a lot of the heavy lifting for you. It also is self-documenting. In other words, you don't have to think about (and potentially mess up) some of the nitty-gritty details. To me, that's a "Good Thing"(tm).