Zend Diary 5: Pay No Attention To The Man Behind the Curtain

So forms finally went through the fire test of configuration and usage. The marketing people that are responsible for delivering the product to the installers. Fortunately an intern was available for entry work taking some load of the primary marketing manager.

The actual use of the program of course brought up many issue that defined the way the admin and system evolved. One example was that the actual content forced a revision of the layout of the entry form and a reconsideration of the sectional organization markup forcing a refactor of the (my how they blow) zend_form classes responsible for the entry of field information.

The Wins...

The other big surprise was how many fields needed to be created for the completion of the project. The initial contractor did his best to spec out the fields, but much work had to be done in the process of linking the form fields to the templates. As well, others had to reformat the Acrobat PDF field targets, and the FDF definitions that mandate how information pours from the database to the PDF had to be worked through.

Lastly, fields that had been defined as isolated checkbox had to be wrapped in a radio button conceit. This meant some major adjustment to the code that interpreted the fields into the FDF; partly because I misunderstood the FDF format requirements for checkbox data.

This was of course a longer process than the other Zend Diaries cover; but the important takeaway for developers is that the investment in learning and tuning ZF paid off with major dividends in the editibility and maintainability of the Forms code. The strong conventions in controller/module/action mechanisms provided easy access and revision of functionality, and the domain pattern as well as my scaffolding admin patterns made addition of columns, refactoring of schema, and alteration of entry mechanisms were a breeze.

Also this project was the breakout introduction of Dojo in the environment of CPF and gave me a chance to throw widgets like the Fisheye for formset navigation and simple mechanisms like Accordian for a popup dialog used to assign fields from multiple tables to form field definitions.

... and the Losses

Rolling off our successes, Dojo was introduced into a recent patch for our principal application. However an attempt to use Zend_Form and Zend_Dojo outside the MVC context was an unqualified failure.

Two things went horribly wrong:

1. The Zend Form is dependant on being placed in the context of a Zend_View; no combination of the Zend_View object and the Dojo helpers managed to reproduce the instant gratification of using the same libraries in the MVC engine.
2. The Zend widget for NumberSpinner was unable to accept a fractional increment; putting an artificial constraint on a widget that the actual Dojo Dijit does not happen is an unfortunate but understandable flaw in the Zend system.

The point being: the social contract that Zend has with developers, that each code module can be used independantly, is seriously broken in the forms department. As emphasized elsewhere in this document, Forms are far from a universal solution and need to be used only where their considerable overhead has payback. This specific project was a perfect example of where they do pay off -- and where they don't.