If offers an easy to understand/use interface for making your controller - and it keeps you from having to write the "giant if/else/elseif" construct yourself.
It's the same reason I use Class::Accessor - it might not be much work to run without it - but it's just really convenient, it's fairly small and it does one thing well.
| [reply] |
CGI::Application does many other things than "a giant if/elsif/else statement"
-- and it doesn't even really do that. (It implements a hash-based dispatch
table that maps a query string to a method; if no match is found, it uses a
default as specified.)
What does CGI::Application do?
- It provides a framework for developing re-usable,
customizable application classes. Simply use the class, pass some
metadata (in the form of a hash) to the constructor, and run() it
- It provides a sane framework for developing applications; each
screen gets a run mode, and each run mode gets a method --
CGI::Application-based classes are incredibly consistent and easy to
debug because it's easy to determine what piece of code is executed
when (look at the dispatch table instead of trying to scan through "a giant
if/elsif/else statement").
- It provides a means for wrapping a number of applications under a
site-umbrella, through it's various cgiapp_*() hook methods. Using these,
you can create a superclass that does security checks, places final
application content in a sitewide template, and creates customized
navigation and sidebars -- but still retain the flexibility of developing
only a single application suite at a time.
If used correctly, CGI::Application can be used as a very good Controller for an
MVC setup -- have it simply do the work of validating and sanitizing input,
passing it to the Model, and piping the Model's return values to the View (a
templating system).
What I like most about it is that, at it's core, it's a very slim piece of code
that simply stays the heck out of my way as I build my applications -- no
extraneous doodads or geegaws are loaded unless I specifically do so myself.
Yes, it's another dependency, but it has very little overhead and benefits that
outweigh the dependency a thousandfold.
| [reply] |