Re: I figured out why I'll never be happy w/ php forms libraries
Posted: Sun Apr 27, 2008 1:52 pm
My examples contained both form generation and submition handling, so it should be enough for a comparison. I too work with the assumption that the code will be dealing with the database (which is the most common case, so that's what my code generation aims at), but it is easily overriden anyway.
@inghamn
Yep, +1 on that.
What I'm missing from your code is a mechanism for reacting to violations of field-specific rules. Sure you enforce some by means of the setter methods, but you would not notice minimal length restrictions for example, unless there's custom code in the save() method.
In my way of doing things object-templates do a good job - they handle very easily the case of supplying default values for a form (something which is not present in the Zend code btw. arborint?)
There are three security problems I can see with your code though:
1. As the very minimum, is_callable() in the controller.
2. No type checking in the model setters.
3. XSS with $_SERVER['PHP_SELF'].
4. (optional
) I don't know what your "blocks" are, but you must be aware that with that .inc extension they will be served "as is" by default, so if there's a remote chance of them containing something useful for an attacker, do protect them with .htaccess
@arborint: How come we're not seeing skeleton examples as well? I haven't checked how it would be used about forms yet.
-----
Btw, something that is not visible in my code, but all my widgets with the specific exception of the login one (not the one in the sample above, I have a hand-written one) happilly work with $_REQUEST - it works well for almost all cases and allows more flexible implementations without much ado (links that partially init a form for example).
@inghamn
the model handles all input filtering and validation. The view escapes all the output.
Yep, +1 on that.
Also agreed, Zend's way and my way seem to be the same as well. It's quite sensible if you think about it.The controller that uses a form is expected to handle what comes back when the form is POSTed.
What I'm missing from your code is a mechanism for reacting to violations of field-specific rules. Sure you enforce some by means of the setter methods, but you would not notice minimal length restrictions for example, unless there's custom code in the save() method.
That's perfectly reasonable in my book. An object is after all (among other things) a collection of values perceived as a logical whole - exactly like what a submitted form is.What jumps out at me right away, is that my form handling stuff definitely assumes a model.
You're not using templates, which would be a candidate for a "form object", so for your implementation it does indeed make little sense.I definitely don't use an object for forms, it always seems like too much work.
In my way of doing things object-templates do a good job - they handle very easily the case of supplying default values for a form (something which is not present in the Zend code btw. arborint?)
There are three security problems I can see with your code though:
1. As the very minimum, is_callable() in the controller.
2. No type checking in the model setters.
3. XSS with $_SERVER['PHP_SELF'].
4. (optional
@arborint: How come we're not seeing skeleton examples as well? I haven't checked how it would be used about forms yet.
-----
Btw, something that is not visible in my code, but all my widgets with the specific exception of the login one (not the one in the sample above, I have a hand-written one) happilly work with $_REQUEST - it works well for almost all cases and allows more flexible implementations without much ado (links that partially init a form for example).