DP Libraries Overview: Introduction

The DP Libraries are fundamentally a loosely-organized collection of solutions to the various problems I've faced over the years. They evolved from specific, "one-off" solutions to address more general problems.

The problems I've solved simply aren't particularly fascinating or unique: they are common to web application development. By extension my solutions to these problems aren't particularly fascinating or original. But they do work!

I hope this material is useful and perhaps even interesting. I am personally very pleased with the applications I've built using these libraries and formalizing them has been very useful to me. I find now that many issues are handled automatically at the outset of a project.

Is this a Framework?

The DP Libraries aren't a Framework in the traditional sense in that they don't provide a grand theory of application development. To put in most simply the code represents the way I build applications (and not particularly the way you should). There are many mature, full-featured Frameworks available for ColdFusion developers that are much more deserving of the auspicious "Framework" label. Here are some of the of the more popular ones (in no particular order):

onTap (which provides an outstanding set of interface abstractions)
Fusebox (one of the oldest and most respected ColdFusion frameworks)
Mach-II (which implements well-known OO design paradigms)
PLUM (which leverages a Windows application to assist with automatic code generation from database models)

Compared to these mature, complete frameworks this code pales by comparison. Installation is mostly manual as is configuration. There is no core philosophy concerning a request life cycle or application management. This isn't the final product of years of computer science research.

At the same time there really isn't a good word available to describe the entire thing. When used together the code really is more than just a collection of individual components (although many of the components can be leveraged individually) since all the pieces work together cooperatively. They are also not just "sample applications" (although you could definitely use them as such) since the core files are portable and adaptive to multiple needs.

So why Bother?

Now that I've done a fine job of dissuading you from using this stuff the obvious question is why should you bother? Well, then, maybe you shouldn't if you're going to be that way! I'm releasing this material publicly for two primary reasons: 1) because I need to document it or I'll forget what I've done and 2) because it's easiest for me to document it publicly (where I know I can find the documentation later).

If somebody else actually finds this stuff useful then that would be extremely nice; but honestly it's not an overwhelming priority for me. In the best of worlds there may be people that not only find it useful, but also help me to expand and improve it (and perhaps even fix a few bugs).

In the end all very selfish reasons I'm afraid.