Sorry the question provoked repetition. I get it now and look forward to post-filtering (if it goes ahead).
On Sunday 09 March 2008 16:43, Matthew Weier O'Phinney wrote: > -- 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.
