It was Fred Brooks who told us that revealing our table structure would make the workings of our apps obvious. Some may think that the wide adoption of object-oriented programming and the advent of web delivered apps obviates Mr. Brooks assertion. I don't.

I had been out of the data driven app development business for quite a while, when I took my current job a little more than a year ago. After coming up to speed on mod_perl and Postgres, I discovered that our apps are strikingly similar to the academic records apps I worked on during my first job, as a registrar's office programmer for a small college, twenty years ago.

While the apps look nicer and generally run faster, their basic ideas have not changed. They are still firmly centered around their data models.

As I worked on the tedious bits of a new app last year I found myself violating the first principle of coding I learned in college: don't duplicate code. (Since I used to teach college Math and Computer Science, I don't use the term Don't Repeat Yourself or DRY. Just try to imagine a college teacher who never repeats himself.) Many others had already discovered and named the bit of code I was writing over and over. It was CRUD (Create, Retrieve, Update, and Delete).

There are many web frameworks. My guess is most of them started to avoid hand coding CRUD. They must have all started on the premise of duplication reduction.

Since we were using a framework, yet were forced to repeat ourselves, we began to think that a major revision of the framework was in order. This led to (Gantry), which kept the best bits of our shop's original framework while eliminating yet more duplication.

At the risk of shameless self promotion -- since I wrote the relevant parts -- I'll assert that Gantry has a pair of nice CRUD schemes. The first, called AutoCRUD, does what you want for the 60-80% of your tables which are dull. The second, called CRUD, takes care of the others, with a bit more help from you.

Having test driven the CRUD schemes in Gantry, I wanted more. I didn't want to have to write an SQL schema file describing the table structure, then go back and write object relational mapping code (for Class::DBI or something similar), and still have to return a third time, to the same data model, to describe its appearance for an on-screen form.

config {
    engine                 CGI;
    template_engine        TT;
    Init     Std           {  }
    CGI      Gantry        { with_server 1; }
    Control  Gantry        {  }
    SQL      Postgres      {  }
    Model    GantryCDBI    {  }
    SiteLook GantryDefault {
        gantry_wrapper
          `/home/pcrow/srcgantry/root/sample_wrapper.tt`;
    }
}
app Contact {
    config {
        dbconn            `dbi:Pg:dbname=contact`
            => no_accessor;
        dbuser            some_user
            => no_accessor;
        dbpass            `$ecret`
            => no_accessor;
        template_wrapper  `genwrapper.tt`
            => no_accessor;
        root
          `/home/pcrow/Contact/html:/home/pcrow/gan/root`
            => no_accessor;
    }
    authors `Phil Crow` => `philcrow2000@yahoo.com`;
    sequence contact_seq {}
    table contact {
        sequence contact_seq;
        field id {
            is int4, primary_key, auto;
        }
        field name {
            is             varchar;
            label          Name;
            html_form_type text;
        }
        field phone {
            is             varchar;
            label          Phone;
            html_form_type text;
        }
    }
    controller Contacts is AutoCRUD {
        rel_location     contacts;
        controls_table   contact;
        text_description Contact;

        method do_main is main_listing {
            cols           name, phone;
            header_options Add;
            row_options    Edit, Delete;
            title          `Contact Management`;
        }
        method form is AutoCRUD_form {
            all_fields_but id;
        }
    }
}
[download]

    bigtop docs/contact.bigtop all
[download]

    Init Std { no_gen 1; }
[download]

You can turn off generation for any backend in this way. Init Std also allows you to control regeneration of individual files, so README can be safe from overwriting while the MANIFEST is kept up to date. Further, you can include no_gen statements at the table and controller levels too (as well as for the whole app, a feature for the truly paranoid).

There are two top level blocks: config and app. In the config block there are statements and backend blocks. In the app block there are sequence, table, config, and controller blocks (plus a set of literal statements). All blocks allow statements; in addition, table blocks have field blocks, while controller blocks have methods. Finally, controller blocks also have literal statements.

After much thought and several abortive attempts at helping you write bigtop files, I began tentmaker. It allows you to edit your bigtop files with a browser (as long as your browser is DOM compliant, think Firefox not IE).

If you've install bigtop and the tentmaker templates that come with it, you can start tentmaker easily enough:

    tentmaker [--port=8081]
[download]