ZF Diary 3

Two benchmarks crossed today: I have been able to generate INI files that feed directly into the core Zend_Forms construct, and I have been able to parse a CSV file and use it to populate my field definition tables. This means there is a direct train from the initial form/field spec to the entry interface. There are still a few dropped fields here and there but the overall engine works. This means I can drop my test forms and fields an use the real world data to drive the application.

Today showcased the strength of the forms module and the Zend_Config[_ini] module. I have begun to appreciate the .ini format over other flat file transports (JSON, CSV, XML) for situations where volume performance is not an issue. the INI format gives you a path to each value, as in this field definition for Zend_Form,

; pdf file element
elements.pdf_file.type = "text"
elements.pdf_file.options.validators.strlen.validator = "StringLength"
elements.pdf_file.options.validators.strlen.options.min = "5"
elements.pdf_file.options.validators.strlen.options.max = "80"
elements.pdf_file.options.validators.regex.validator = "regex"
elements.pdf_file.options.validators.regex.options.pattern = "/\.pdf$/i"
elements.pdf_file.options.required = true
elements.pdf_file.options.label = "PDF File name"

so you don't have to digest context vertically. I wouldn't use it for a networked/AJAX application but its nice for locally driven functions.

I'm developing functionality in the admin end for editing field definitions after they are loaded from the CSV. This will become important to resolve entry errors. In the future we probably won't be creating any form definitions completely from the admin (at least I wouldn't want to) but it is good that we aren't bound to only one way to enter definitions.