Kevin McArthur wrote:
Darby, I've got priorities in the Zend_Pdf project unfortunatly -- I'm
happy to run ideas by and do lil patches here and there, but my roles
firmly within the Pdf stuff and I unfortunatly don't have time even for
that these days (work ft, run neutrality.ca and am writing a book under
contract, so lifes busy)
Understood; I sincerely appreciate your helpful feedback! :)
I'd suggest more thought on tying your filter/validation stuff to the
request api. The common/standarized way of handling form data would be
really useful. I'd also implement a RecursiveIterator for the
collection, so that it can handle all the right type of filtering
scenarios. (Maybe filteriterator integration?)
Aye, there's the rub. First, I have attempted to propose a design for
filters and validators such that they would support various use cases
such as filtering input (e.g., $_REQUEST), escaping output, and building
form controllers.
As for recursive iteration, I'm unsure whether it makes sense to do this
at the level of a filter or validator component. For example, if I have
an unknown number of form fields, each named "emailX", where X is a
positive integer, starting at 1 and incremented for each field, I would
want to be able to loop over each of these fields, having each value
filtered and validated the same way.
To solve this use case I think it makes sense in the form controller to
create a single set of filter and/or validator chains that can be used
with each of the "emailX" fields. That is, the same filter/validator
chain could be used for each field, a "one"-to-many relationship. In the
controller I would loop over each "emailX" field, where each field is
contained in the form's collection of fields, applying the same
filter/validator chain for each "emailX" field when needed. In this case
I think it makes sense that either a Form or Request object would
provide the container of fields to the user.
Right now with the framework there are too many sources of input 1)
parameters coming frm the router 2) apache environment variables 3) get
variables 4) post variables 5) cookies 6) sessions.
Consolidating these into an encapsulated environment under the Request
object might make sense.
Yes, I see the value in offering these input data through a unified
Request object. The current Zend_Filter_Interface in the laboratory
supports this use case in the theoretical sense, perhaps akin to the
filter pattern described here:
http://www.faqs.org/docs/artu/ch11s06.html
I see no reason that a framework Request object could not make use of
filters and validators under the currently proposed design.
Perhaps we should discuss what this would solve, however. Particularly
helpful in situations like these is having use case scenarios in code
illustrate how such a Request object might be used [in an ideal world].
I guess I'm just trying to understand what such integration would solve
before trying to decide how to do design it.
I don't have a total solution, but the current approach seems very
stand-alone when a more integrated approach might be better?
I don't find these goals to be opposition to each other. I agree that
the currently proposed designs for filters and validators are not fully
integrated with the rest of the framework [yet], and I also agree that
we should explore the problems that such integration would solve. ZFI is
a first attempt at such integration, and I think most of us would agree
that the design needs improvement, as evidenced by your patch that
provides iteration support. But there are two different design
considerations:
(1) Design filters in such a way as to support various use case
scenarios (e.g., input filtering, escaping output) - in progress for 0.7.0
(2) Improved framework integration of filters and validation (e.g.,
input filtering), which depends on (1), planned for post-0.7.0
Best regards,
Darby
