ZF Diary 4

The Long Haul

Much of this site was done with an abstract view of the data components. After a bug fixing hiatus, I have gotten back to forms. I have realized that there needed to be a medium level of organization for form data between forms and fields -- effectively, fieldsets of related fields which I am calling "sections" (an admittedly weak name choice.) The printed forms themselves organize information in clusters, and presenting all the fields in one fell swoop is just too damn ugly for words -- as well as making the process of batting the user back due to validation errors both chronic and confusing.

Rather than using Zend's Subform technology which would probably have done a good job at modelling this "chunking" I decide to create ini nodes for each "chunk" and use my form domain object to generate a zend form based on each section. Because INI files have at their top level "sections" of their own, I can store field definitions for each section in the same file; even better, my original "fields" section can contain all the fields in the entire form, so the client can still enter and edit all the fields on the same page if they want.

Adding the section conceit into the admin area was actually pretty simple -- create a form for the entry and custom handlers for checkboxes to include/disinclude fields within the section. The inclusion mechanism was a simple foreign key on the field defs themselves.

Every Field is Sacred

I kind of "sucked in" a huge amount of field data without knowing/caring how the fields interact with each other. This might qualify as a mistake, but it got me this far and therefore, paid off. However it also meant that design choices were made that now need to be adjusted a little.

A big "To Do" is that the CVS used to load field defs includes a lot of "see above", meaning I'll have to create some sort of "master field" convention. It was made clear by the client that even seemingly synonymous fields should be individually editable by the client.

Also because paper forms are what they are, many "checkbox" items are intended to have radio button functionality ("check one"), so another relational concept will have to be overlaid into the fields. "Have" being a loose concept; the forms will function as long as the user doesn't check more than one, the system works.