Skip to end of metadata
Go to start of metadata

Zend Framework: Zend_Validate_Array Component Proposal

Proposed Component Name Zend_Validate_Array
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Validate_Array
Proposers Boris Tomi?
Darby Felton, Zend liaison
Revision 1.1 - 22 March 2007: Created.
1.2 - 09 December 2007: Small changes (wiki revision: 19)

Table of Contents

1. Overview

Zend_Validate_Array is 'high level' validator created for easier filtering and validation of arrays ($_POST, $_GET). It is intended to give you possibility to create end-user error messages (and use Zend_Translate if you require).

Latest implementation is [Zend_Font - Karol Babioch^Array.php.3.zip].

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

4. Dependencies on Other Framework Components

  • Zend_Validate_Exception
  • Zend_Validate_Interface
  • Zend_Filter_Interface

5. Theory of Operation

This is quite simple solution for validating array values (usually $_POST, $_GET, ...). It uses Zend_Filter_* and Zend_Validate_* classes for filtering and validation. You also can add custom messges for validators. That way you can have error messages ready for end user.

So first you have to create object:

Constructor needs to know what keys () will be used. They are passe as array.

Next we need to add some filters and validators:

Then we do validation:

6. Milestones / Tasks

  • Milestone 1: Initial design
  • Milestone 2: Unit tests
  • Milestone 3: Documentation

7. Class Index

  • Zend_Validate_Array

8. Use Cases

UC-01
UC-02 - realworld example

9. Class Skeletons

Labels:
validate validate Delete
array array Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

4 Comments

comments.show.hide

  1. Mar 26, 2007

    Pádraic Brady

    I'm guessing there will be two or three similar proposals over time until they are merged into something definitive for the Zend Framework. But it's a good start to have something. A few comments:

    • Why the ampersand reference indicator in the class skels for add* method? (just curious )
    • How do you intend filtering for required vs optional input values? (i.e. an implicit NULL check)
    • Is there a way of integrating equality as a comparison validator? Would avoid the password type complications if the validator knew to compare two required values (both not NULL, both identical).
    • Complementary would be a userland Request object - since apparently the one in the ZF was never intended to be used in userland code. This would handle request normalisation (e.g. magic_quotes reversal and such). Could be an ArrayObject and still work, and allow the user know the HTTP Method just as easily as checking $_POST/$_GET. The point here is to push an Object Oriented abstraction across the superglobal of choice. You could extend this further having context Request objects: Request_Raw, Request_Filtered, etc. And allowing the superglobals to be discarded (being raw). That's just one idea of any number of implementations of PHP though but it allows for the data to be identifiable by the Request class type.
    • It would be cool to see a Factory which can create the validator chain from a configuration file. Would reduce complexity for those who don't want to edit controllers even further. That also reduces the ability to "fine tune" validation from within the controller - but that's a case by case developer decision.

    1. Mar 26, 2007

      Boris Tomi?

      • Reference indicators - I do not know are they required but I want to make sure that you do not get copy of object and that is clearly visible that you are getting same object back.
      • Required vs. Optional - I think that this should be solved with some validate class(ex. Zend_Validate_Required). It is quite simple to create such class. Than you could use addValidate method. Also I can change constructor to take two arrays:

        This is simple, clear and easy to write solution but if we want to add another thing to constructor it is limited. Other little ugly solution is that constructor take one array in following form:

        or we coudl have setRequired(array $keys) method

      • comparison validator - this should probably be done also with new Zend_Validate_Equality (or something like this) class which will be aware of Zend_Validate_Array. Zend_Validate_Array will have to have methods for returning values. This validator will be very specific (could be used only with Zend_Validate_Array) and I am not sure this is good. Probably my other proposal could answer this problem better because there will be separate interface (ex. Zend_Runner_Interface) which could have such methods. Things like this are quite specific for example if you want to validate captcha. So maybe it is the best that we left specific things out of general implementation. Just now I got idea how to solve this. Maybe the best should be to extend this class and implement such functionality. I am writing this quickly so maybe there could be some errors:
      • I am not sure I understand what is your point when talking about Reguest object. Anyway I think that Request object with this solution does not have any connection. This is ment to be general Array validator. If we have some interface such I will try to propose (Zend_Runner_Interface) then classes such as Zend_Form could implement such interface and also implement connection with Request object.
      • Factory - This is probably more required for ex. Zend_Form class than this one but if I see need it could be implemented.

      As you can see I will have one more similar proposal (Zend_Runner). That should be more generlal solution. With that proposal it will be possible to apply it to different objects (Forms, Array, .... ).

  2. Apr 13, 2007

    Markus Wolff

    Hey, someone else who sees the need for this, great

    I had a similar idea a while back, but never turned it into an official proposal because the Zend guys indicated that they were working on something like this on their own - but so far, no code or proposal has been introduced :-/

    Anyway, I love your approach except for two little details:

    1. Why tell the constructor which keys I will use? After adding rules via addFilter() and addValidate() (which, by the way, I'd name addValidator() or, shorter, addRule()), it should be quite clear to the object which keys will be needed. No data needs to be passed to the constructor.

    2. I dislike the idea of having to do further checks after calling the isValid() method. If it's valid, it's valid - period. Things like equality to another field's value should really be handled by a custom validator class that is simply added to the validation rules.

    Regarding the question of how to handle required fields, I think it would be best to make a custom validator class for this as well, that just checks if the value is present.

    Having said all that, I'm really looking forward to seeing a class like this in the framework!

    CU
    Markus

    1. Apr 16, 2007

      Boris Tomi?

      Thank you for your comments. I will try to improve this and incorporate what you have suggested.

      What you think should addRule take Zend_Validate_* and Zend_Filter_* classes so there will not be need for addFilter or you meant that addRule take just Zend_Validate_* and addFilter Zend_Filter_* classes.

      You and definitely right that there should not be further checks after calling isValid(). I think that will be much more easier that Zend guys implemented some interface for 'high level' validators. Maybe they will.