After a week of solo development I have my first meeting with the client. The short, impromptu meeting focuses on the database.

One of the things that amused me about this particular client is that they regarded every relationship as the foundation for a HABTM* table.

To prove that non HABTM relationships exist and can be a good thing, I make a point of using foreign keys for all the joins in the fieldset model.

I'm sure you can tell where this is going...

Turns out that the forms can belong to one or more formsets; the formset foreign key in the form table is dysfunctional.

Adding an Admin area

For this and other reasons, I focus on an admin section so that I can view edit and do things like allocating forms to formsets with a checkbox series.

I accomplish the admin section with an extra module. Modules in Zend Framework are not what they are in most other systems: a module is a namespace with a seperate series of controllers and views. **

I slap out a partial for list and detail listing, but it becomes evident that in order to mix in controls with the list scaffolding, I need an independant class structure to transport data from the domain objects to the list/detail renderers.

The report class represents a single row, but can contain sub-report objects for related data (the forms in a formset, for insance, and/or the fields in a form). The report class tree mirrors the model class structure, with allowances for controls (which are actually just hyperlinks). I generate the controls with a series of helper classes that take in the current row.

Once I have a skeletal admin area worked out I begin adding edit forms. These are .ini file driven stock Zend forms. I land on a two - action strategy for form resolution -- [controller]/edit/id/[value] for the form start, and a [controller]/editvalidate/ action that is the destination of the form on the ../edit page.

At this point the plan is to initate the data by parsing a spreadsheet of forms and fields given to us by a contractor, so the /new actions will wait til there is more "there" to the project.

Miscellany

I forgot to mention a few development branches in the earlier blog. A simple .ini file handles the database transport.

The session transport is handled with a simple extension of the Zend_Session class. its especially useful for simulating updates to the mock database during the unit test -- new, updated or deleted records are saved to the namespace of their tables by my Zend_Session router.

Zend's Initializer plugin allows for an "environment" variable -- this is a useful switch for me, as I can switch to my mock database within the unit tests, but it also allows for custom database keys for different developers, staging, and the live site.

The development branches to date

So at this point there are several branches of classes in this project:

• The two modules, default and admin
• The controllers under each module
• The views that display the result of (most of) the controller actions, also divided by module
• A series of domain objects for each table, paired with a Zend_Table stub. These exist in the default module but are acessable system wide.
• A series of report transports for each table (or at least each table I want to manage in the Admin area)
• A few form classes (Zend_Form descendants) for editing records in select tables
• A handful of classes for user authentication, session management and system configuration

_{*Has And Belongs To Many -- a relationship type I spent months searching for and finally found in the Cake PHP docs. a HABTM table with two keys that relates two records to each other -- usually in a parent/child relationship, but alternately as part of a non-oriented network or a set.}

_{**You could, for instance, put several different sites or tools under the same framework by giving each site its own subdirectory. In this case, the branch /forms/admin/[controller]/[action] branches to the admin's controllers, and /forms/[controller]/[action] branches to the default module's controllers. (as long as you don't need an "admin" controller in your default module, you're safe...)}