#367: Fix some of the borderline inoperable ugliness of the validation system
-----------------------+----------------------------------------------------
Reporter: david | Owner: dominik
Type: task | Status: new
Priority: high | Milestone: 0.11
Component: validator | Version:
Severity: blocker | Resolution:
Keywords: |
-----------------------+----------------------------------------------------
Old description:
> Some suggestions:
> * Move all error related methods from Request to !ValidatorManager
> * Make things simple
> * Allow more than one error message per field?
> * Method to retrieve all errors of a field
> * Method to retrieve all errors of a field and validator
> * Method to retrieve all errors of a validator
> * Method to retrieve all errors of a validator and field (with foo[]
> support)
> * Method to check if a field has any errors
> * Method to check if a field has errors set by a validator
> * Method to check if a validator has any errors
> * Method to check if a validator has any errors for a field (e.g. all
> foo[] fields)
> * Make things consistent
> * Is information, where feasible (e.g. severity), inherited correctly
> from parent validators?
> * What happens if a parent validator defines an error message, too?
> * How are these accessed? AndValidators cannot be queried by field
> name directly? Do all children have that message in them, or is it just
> in the and validator itself? How do we do it?
> * What happens to the "default" error message (the one without a
> {{{for}}} attribute)? Should it be added if another error message was
> set? I think no, because for a minlength string validator, it would be
> stupid to see "Please enter a name", too, if the field has been filled
> in, but with too few characters.
> * Make things useful
> * Allow getting specific validators at runtime
> * Validator named "foo"
> * All childs of validator "foo"
> * All validators for field "blah"
> * Allow modifications to validators at runtime (i.e. in
> {{{registerValidators()}}})
> * Adding (also as "child of "foo")
> * Removing
> * Changing (Properties, Fields, Depends/Provides and such)
New description:
Right now, the validation system has some serious flaws:
* It's often not possible to make a connection between errors and their
fields
* You cannot retrieve and modify validators at runtime (e.g. in
{{{registerValidators()}}}), and therefor not add child validators to an
existing one etc
* You cannot get information about the status of validators or fields
after validation, e.g. "did this isImageFileValidator report that field
foo is an image or not?", which is very important to many people
Some suggestions:
* Move all error related methods from Request to !ValidatorManager
* Make things simple
* Allow more than one error message per field?
* Method to retrieve all errors of a field
* Method to retrieve all errors of a field and validator
* Method to retrieve all errors of a validator
* Method to retrieve all errors of a validator and field (with foo[]
support)
* Method to check if a field has any errors
* Method to check if a field has errors set by a validator
* Method to check if a validator has any errors
* Method to check if a validator has any errors for a field (e.g. all
foo[] fields)
* Make things consistent
* Is information, where feasible (e.g. severity), inherited correctly
from parent validators?
* What happens if a parent validator defines an error message, too?
* How are these accessed? AndValidators cannot be queried by field name
directly? Do all children have that message in them, or is it just in the
and validator itself? How do we do it?
* What happens to the "default" error message (the one without a
{{{for}}} attribute)? Should it be added if another error message was set?
I think no, because for a minlength string validator, it would be stupid
to see "Please enter a name", too, if the field has been filled in, but
with too few characters.
* Make things useful
* Allow getting specific validators at runtime
* Validator named "foo"
* All childs of validator "foo"
* All validators for field "blah"
* Allow modifications to validators at runtime (i.e. in
{{{registerValidators()}}})
* Adding (also as "child of "foo")
* Removing
* Changing (Properties, Fields, Depends/Provides and such)
--
Ticket URL: <http://trac.agavi.org/ticket/367#comment:1>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
[email protected]
http://lists.agavi.org/mailman/listinfo/tickets
