-- Laurent Melmoux <[EMAIL PROTECTED]> wrote
(on Tuesday, 04 December 2007, 10:36 AM +0100):
> I’m already using the laboratory Zend_Form in my current project. :)
Wow -- I didn't expect people would be using that code already!
> I have some suggestions :
>
> CLIENT SIDE VALIDATION
>
> I extended it to support validation rules format from Zend_ Filter_ Input
> with Zend_Form:: setValidators() and Zend_Form:: setFilters().
>
> As those validation rules are a php array I’m planning to use them with a
> view helper to generate the client side validation. So basically for each
> JS library you only need the right view helpers. So if Zend_Form would be
> able to return all the validation rules as an array it should be easily
> implement.
Each element can grab its validator chain using getValidatorChain(); you
could put this into a helper:
$validators = array();
foreach ($form as $key => $element) {
$validators[$key] = $element->getValidatorChain();
}
The only problem is that this returns a Zend_Validate object, which
currently has no introspection on its validators... and even if it did,
each one is a PHP object itself.
It's an interesting idea, but there's a lot of functionality outside of
Zend_Form that would need to be done to support it.
Have you considered using XHR requests for validating server-side
individual elements?
> I18N
>
> Another point that I would like to be considered in Zend_Form is i18n
> issues with the errors messages.
>
> *Validation errors*
>
> In my current version I’ve implement a errorManager like the one develop
> by Bryce Lohr with Zend_Validate_Builder
> (http://framework.zend.com/wiki/display/ZFPROP/Zend_Validate_Builder+-+Bryce+Lohr)
> So for errors message Zend_Form proxy to the errorManager. I have 3 levels
> of errors management :
>
> * Zend_Form::setDefaultMessages($validatorMessages);
> Set the default for all the error messages for all the validators.
> $validatorMessages is an array contenting all the translated messages
> something like :
>
> array('NotEmpty' => 'Le champ est requis !',
> 'EmailAddress' => array(
> 'Zend_Validate_EmailAddress::INVALID' => "L'adresse email n'est pas
> valide",
> ….
> ) ….
> );
>
> It is mostly use internally as my implementation is local aware and will
> try to load the right validator messages.
>
> * Zend_Form::setMessages($someValidatorMessages);
> With this method I can overwrite some default message if I think they are
> too generic.
>
> * Zend_Form::setMessage();
> With this method I can overwrite some default message for specific fields.
>
> * The “message” key of the validators rule will overwrite all messages
> set with those methods.
I've got several thoughts on this.
Right now, Zend_Form_Elements returns messages by pulling them from the
Zend_Validate object associated with it. This in turn aggregates
messages from the individual validators associated with it.
The messages and errors provided by Zend_Validate validators are
typically from class constants:
Zend_Validate_EmailAddress::INVALID == 'emailAddressInvalid'
Zend_Validate_Alnum::NOT_ALNUM == 'notAlnum'
etc.
So, my thought is that the error view helper would pass these messages
through Zend_Translate (or we'd offer separate error helpers for
translated vs untranslated messages). This covers the i18n aspects you
mention.
Now, regarding the setting of messages. The big issue is that
Zend_Validate does not allow you to set messages for a given validator,
nor does it allow you to retrieve the individual validators from it in
order to set messages after the fact. I think this is an improvement
that's in the scope of the project, and I'll discuss it with Darby.
those changes are made, you could very easily fetch individual elements
and set individual validator messages.
However, I like the idea of a single error message for an element as
well, instead of aggregating all of them. I'll take this under
consideration.
> *Labels*
>
> Zend_Form::setLabels();
> Could be useful too to set all labels at once, if you store all your model
> translation in a format support by Zend_Translate.
I'll take that into consideration as well. Perhaps having the forLabel view
helper able to pass the label through Zend_Translate would be sufficient?
Thanks for the great feedback!
> Gunter Sammet a écrit :
>> Besides AJAX validation(/filtering), maybe some autmatic JS validation
>> code would be nice. E.g. regex validation works well on server and
>> client side. And all the expressions would be the same. Just some
>> extra functionality to pull in the JS code into a validation function.
>> Not sure how easy it would be for element dependencies but should be
>> possible as well. All the existing validation helpers should be easily
>> adapted to provide some JS validation. Thoughts!!!
>>
>> Gunter
>>
>>
>>> Not yet; I hope to have a full proposal out later in the week; more on
>>> that below. The ideas I'm looking at now are:
>>>
>>> * "sectioned" forms -- i.e., forms that have grouped items
>>> * Element dependencies (elements whose validations depend on the
>>> values of other elements)
>>> * Multi-page forms
>>> * AJAX interaction:
>>> * Validating single or multiple elements via AJAX
>>> * Autocompleters
>>>
>>>
>>
>>
>
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
