Understanding Padsite's Architecture
History and Overview
In my experience, it seems that one of the most time-consuming parts of building a dynamic website is building all the backend reporting that supports it. In fact, a fitting acronym, C.R.U.D., is used among programmers to describe the Create, Read, Update and Delete functions that are written over and over again. It's the least fun part and it represents a large proportion of the code.
Padsite originated from a humble custom tag that was meant to save me some time writing SQL. It would take a list of numeric field names and a separate list of string field names and perform an action (insert, update, delete) given the table's name, the record ID and the scope of the incoming data (url or form). String values were qualified with single quotes and numeric values were passed through ColdFusion's Val() function on their way into the database. This proved to be a good timesaver but I knew more was possible.
Later, that custom tag was expanded into a small app that used a schema to keep track of all my tables and all the fields within those tables. This schema kept track not only of the name and datatype of each field but it also allowed me to assign subtypes as well. For example, a field with a varchar datatype might have one of the following subtypes asssigned to it: email address, phone number, url, formula (for calculations), etc. In addition to the most common, standard data types such as bit, int, money, text and varchar, Padsite adds some of its own data types which i will describe later.
Taking advantage of this schema, I develped two 'agents' (basically just controller templates) named reporter and editor whose job was to generate my reporting and editing pages for the backend. These generated pages were a lot like controllers although I was not yet familiar with MVC architecture when I started this project. Versions 1 and 2 of Padsite were written using cfincludes but with version 3, Padsite was restructured into a full-blown Model-View-Controller architecture utilizing ColdFusion's application.cfc framework.
Padsite still centers around the reporter and editor agents but they are now packaged as CFCs.
The Reporter Agent at a Glance
The reporter's job, given the name of the table to be read, is to provide the records as well as the table's schema in a structure typically named 'Report'. The Report struct contains all the records and additional information needed to display them. The controller then renders the report page using a set of views that support sorting tabs, row queueing and more.
The reporter agent resides in /padsite/services/reporter.cfc and its main function is psReadRecords.
The Editor Agent at a Glance
The editor's job is more complex. It provides the common insert, update and delete functions but it also provides a search function that shares the same basic views as the editor. There are plans to add a read-only viewer but that hasn't really been needed so far.
The editor agent resides in /padsite/services/editor.cfc and its main functions are psReadRecord, psInsertRecord, psUpdateRecord, psDeleteRecord and psSearchRecords.
Custom Data Types
As mentioned, Padsite's schema adds some additional higher-level datatypes to your toolbox.
- filter: allows for a drop down menu in Reporter that allows you to quickly select records with a value based on a list of all distinct values in that column
- iframe: allows for an inline frame summary (or mini-reporter) inside of an editor controller - for viewing child records (single-to-many)
- list: allows you to create groups of records as lists of ID numbers
- custom: allows you to interrupt padsite's normal processing and execute your own custom code for viewing, editing or even calculating a given field