After some conversations with Paul and Mike, in recent months I realized that while I often announce new releases of Cgiapp, I rarely explain what it is or why I develop it.

I got into trouble on the PEAR list when I tried to propose it for inclusion in that project, when I made the mistake of describing it as a framework. (This was before frameworks became all the rage on the PHP scene; PEAR developers, evidently, will not review anything that could possibly be construed or interpreted as a framework, even if it isn't.) I mistakenly called Cgiapp a framework once when considering proposing it to PEAR. But if it's not a framework, what is Cgiapp? Stated simply:

Cgiapp is the Controller of a Model-View-Controller (MVC) pattern. It can be either a front controller or an application controller, though it's typically used as the latter.

As a controller, it provides some basic, configurable routing mechanisms to determine what should be displayed for a given request, a simple registry for configuration variables and for passing variables around between method calls, error handling, hooks into a template engine, and hooks into pre/post application and request operations.

When developing applications using Cgiapp, you operate on the idea of one display screen, one method. You define a hash table mapping display screens to methods, and either indicate a query parameter or a segment of the request URI that will indicate the display requested; when the request comes in, the appropriate method is called. In Cgiapp terms, these are called "run modes".

What makes Cgiapp so enticing for me as a developer?

• Object orientation. Cgiapp is inherently object oriented; to use it, you must create a class that extends Cgiapp (or Cgiapp2!), and map methods to actions. There's no getting around it. Because of this, applications are namespaced, portable, and testable.
• Reusability. Because each application is a class, and each application instance is triggered from an instance script, and because you may pass configuration variables to the class from the instance script, Cgiapp-based applications are inherently reusable. This makes it easy to distribute applications, as well as to reuse them in multiple site locations. As an example, I have used article applications in multiple locations, accessing different article stores -- but using the same article application class. Each had a different look and feel, sometimes within the same site, sometimes in different sites, but I merely needed to change the data store and the templates to achive the differentiation.
• Extensibility. Ever code something, and then need an application that duplicated much of the functionality, but added some twists to it? One such example: I had a small gallery application, and later needed an e-card application. The latter was basically a gallery type of application, but when selecting an image, needed to display an e-card form, and also needed to handle the results of that form. I simply had the e-card class extend the gallery class, added a method, and created a new view template for the image view. Total extra work: about an hour or so.
• Developer freedom. Because Cgiapp is not a framework, and, indeed, only a single class (that changes in Cgiapp2, but only because Cgiapp2 has some helper classes), it gives a lot of freedom to the developer. You can pick and choose what templating system you want to use. Or what data storage mechanism you want to use. Or how you'll handle sessions. Or whether you'll use pretty urls or GET parameters (or allow one, but default to the other). In a nutshell, it allows the developer to cherry pick the libraries and components they want to use in their application.

It's the last point, above, that really separates Cgiapp from most other MVC frameworks I've reviewed. Most frameworks tend to give you everything, package it up, and try to sell it to you as the developer: "Use only the tools integrated in our solution, we can't guarantee best performance otherwise." Cgiapp doesn't do that. Cgiapp let's the developer call the shots and say, "I'm familiar with such-and-such library and want to use that in my MVC application," or, "I like such-and-such template engine, and want to use that," or, "I need my application to work regardless of whether mod_rewrite is available." As examples, I've done extensive development with Cgiapp that used Smarty and PEAR::DB; I've also used Savant and Zend_Db. I have users that report they love ADODB. I've used pretty URLs, but I've also often used GET or POST to determine the current run mode. The point is, Cgiapp merely provides an easy to use controller into which you can plug the model and view of your choice.

The other very important aspect of Cgiapp, to me, is application reusability. With Cgiapp2, this becomes even more of a feature, as applications can be customized via run-time plugins from the instance script. If an application has to be tied to a particular site structure, it's never completely reusable. But when it is configurable per instance, via templates, data store, and/or pre/post operation actions, it becomes distributable and pluggable. This means the possibility of applications like forums, galleries, contact forms, article systems, etc. that can be dropped in anywhere in a site and easily configured to match that site's look and feel. To me, this is invaluable.

With this explanation of Cgiapp under my belt, I plan to start blogging about uses of Cgiapp and Cgiapp2 to show how it can most optimally used. In the meantime, feel free to comment and ask questions!

Update: Changed language in third paragraph to put emphasis on Cgiapp as not a framework instead of anti-PEAR slant.