-- Mark Maynereid <[EMAIL PROTECTED]> wrote
(on Saturday, 08 March 2008, 06:31 PM +0000):
> On Saturday 08 March 2008 13:53, Matthew Weier O'Phinney wrote:
> > I'll consider a postfilter post-1.5.0 GA release when I start looking at
> > associating forms with models.
>
> I sense I would welcome this as my efforts on CRUD seem to be focusing me
> towards these issues from a generic standpoint. Perhaps like some others, my
> table classes provide all meta info to enable automated form building.
>
> But wouldn't this post-filter addition also begin to make Zend_Form
> completely
> overlap ZFI? I did ask about ZFI's role some time ago back when optional
> fields in Zend_Form were not yet supported and never quite understood why ZFI
> was not leveraged wholesale by Zend_Form (perhaps with BC adaption to ZFI)?
>
> With a postfilter addition being considered now, it looks to me like
> convergence, and so I can't help wondering again if ZFI should be serving
> this role for Zend_Form?
>
> Sorry if I don't understand it well enough but it just seems to me like
> fairly
> significant duplication. Which is better? Added BC support for Zend_Form's
> needs within ZFI, or, what looks to me like a trend towards duplication with
> ZFI (perhaps for sounds reasons)?
As I've mentioned several times on the list and in issue reports, ZFI's
design does not fit Zend_Form. I tried, but the problem is summed up
with the following:
* Zend_Form requires that filter and validation chains be per-element:
* to allow re-use of an element with multiple forms
* to allow validating single elements
* to allow Zend_Form the ability to do partial validation
* Zend_Filter_Input operates on *sets* of data
* The data set is either valid or not, depending on whether or not
all items in the set validate
ZFI does not work for Zend_Form's design because the form itself has no
awareness of the filter and validation chains; it delegates all of this
to the elements. This delegation is necessary to, as noted, allow re-use
of elements, as well as easy customization of existing elements on a
per-form or per-element basis.
Basically, I see ZFI's role as being for those who have a need for a
lightweight solution -- they may have very simple form needs, or they
may be tying validation into their models directly, and have no need to
have the models render their own forms for any number of reasons: they
may be using the model with web services such as SOAP, REST, or XML-RPC;
they may have CLI tools that interface with the model; etc.
Zend_Form is for those who need to be able to *render* the various input
fields as forms, and who may need to be able to validate individual
elements or subsets of elements. Right now, that rendering is
restricted to XHTML, but you could easily add XForms, FPDF, GTK, or
ncurses into the mix to have other types of forms. Regarding validation,
ZFI requires you to validate a *set* of data; you can then query to see
if individual elements were valid, but it is not designed to validate a
single element or a subset of elements. These two things significantly
differentiate the purposes of the two classes.
Yes, there is some duplication and overlap. They do very similar things,
but they do so with slightly different goals and with different
responsibilities. You could certainly engineer Zend_Form to act simply
as a filter/validator chain ala ZFI (particularly as you can now disable
loading decorators), but it's a heavier-weight solution than ZFI.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
