Open pittyplatsch opened 8 years ago
Yeah, one could potentially use setOptions()
to set the 'callbackOptions'
but especially considering the given examples (where the 'callback'
is set in the constructor) I'm sure the original intention was to use setCallbackOptions()
, otherwise $options
would be not the same in the three examples. It also saves the need for a nested array (['callbackOptions' => […]
), so is imho cleaner and explaining a validator specific function in the right place.
On another note: the associative array in your examples will work, but since the arguments are later merged to be used with call_user_func_array()
there's no need to define any indexes. Also you're not using them in your callback function.
One rationale for keeping the docs as-is is that setOptions()
is used internally by the constructor, and thus represents the options that would be set in module or application configuration for a validator instance.
Leaving this open for the time being.
I unfortunately don't know anything about module or application configuration as I'm using the component outside the framework – is it very different from using the InputFilter\Factory
where callbackOption
needs to be set if one wants to use it?
$factory = new \Zend\InputFilter\Factory();
$inputFilter = $factory->createInputFilter(array(
'password' => [
'name' => 'password',
'required' => true,
'validators' => [
[
'name' => 'callback',
'options' => [
'callback' => function($value, $context, $option1) { return $option1; },
'callbackOptions' => [
false
],
],
],
],
],
));
$inputFilter->setData(['password' => 'p@s$w0rd']);
echo $inputFilter->isValid() ? "Valid form" : "Invalid form";
The issue is that both
setOptions()
andsetCallbackOptions()
are valid functions, each with their own usecase:or:
This is outlined in the sentence that you may have overread: