# RFC: New Validation Component

**URL:** <https://discourse.laminas.dev/t/rfc-new-validation-component/208>\
**Category:** Contributors\
**Tags:** zend-validator\
**Created:** [July 19, 2017, 7:10pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208 "2017-07-19T19:10:45Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [September 12, 2017, 9:07pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/21 "2017-09-12T21:07:07Z")

</div>

I’ve started the repository under my own username on github at this time:

- [https://github.com/weierophinney/zend-datavalidator](https://github.com/weierophinney/zend-datavalidator)

What I’ve done at this time:

- I’m using the name zend-datavalidator, with the namespace `Zend\DataValidator`.
- I’ve modified the proposed interfaces and traits to use the `Interface` and `Trait` suffixes pending a decision on how these artifacts should be named; consistency with existing components is likely more important at this time than other concerns.
- I’ve added a `ValidatorChain` implementation, which relies on a `ResultAggregate` implementation to deliver the results. The chain only aggregates _concrete validator instances_, and executes them in the order in which they are attached (no container or priority awareness).
- I’ve provided a `Between` validator implementation to demonstrate how validators might be written. It in turn extends an `AbstractValidator` implementation; this only provides some basics around failure message codes/templates, as well as a mechanism for building a validation failure result based on one or more such templates.

I’ve not written documentation yet, pending review by interested parties; use the tests to get an idea of how the component works.

My feeling at this time is that validator chains should likely be built from concrete instances. Since both validators and chains are stateless, this means that the services can be safely shared; I would expect discrete factories based on the needs of your application and/or individual data sets.

---

<div class="post-metadata">

**Author:** ![Seryus](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/seryus/32/216_2.png) [@Seryus](https://discourse.laminas.dev/u/Seryus)\
**Post date:** [October 17, 2017, 11:33am UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/22 "2017-10-17T11:33:29Z")

</div>

Why should the Result object contain the validated value? Provide the value is not the responsibility of validators, nor of the Result object, is it ?

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [October 17, 2017, 11:52am UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/23 "2017-10-17T11:52:44Z")

</div>

The idea is that this will eventually be part of an input filter; in that situation, we would want access to both the filtered/normalized value and the raw value.

Additionally, encapsulating the value allows passing the result as a single message, giving the receiver access to the value as well.

Finally, having the value present allows it to be passed along with any other contextual variables to the ValidationErrorMessage instances for purposes of reporting or logging; we want to delay creation of these instances until they are requested.

---

<div class="post-metadata">

**Author:** ![ocramius](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/ocramius/32/23_2.png) [@ocramius](https://discourse.laminas.dev/u/ocramius)\
**Post date:** [October 17, 2017, 12:23pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/24 "2017-10-17T12:23:51Z")

</div>

Retaining the value is not the responsibility of the validator, as that  
makes the validator not reusable in the context of concurrent or shared  
(across layers) usage due to its stateful nature.

Getting rid of the value/messages from the validator was the first step in  
this design.

Marco Pivetta

[http://twitter.com/Ocramius](http://twitter.com/Ocramius)

[http://ocramius.github.com/](http://ocramius.github.com/)

---

<div class="post-metadata">

**Author:** ![Seryus](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/seryus/32/216_2.png) [@Seryus](https://discourse.laminas.dev/u/Seryus)\
**Post date:** [October 18, 2017, 9:37pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/25 "2017-10-18T21:37:15Z")

</div>

@matthew

The current InputFilter component already retains the raw values, and the new InputFilter proposed by Bakura (which seems will be used for 3.0) retains the raw and filtered values.  
We can still access to the raw values using InputFilter even if the validator result does not contain it.

When using validators without InputFilter, the raw value is passed to the validator, so the raw value is already available.

If ValidationErrorMessage instances must use the raw value, it could be passed by the validator to the ValidationErrorMessage constructor in the same way that contextual variables are.  
As validators are now stateless, the raw value used to validate is a contextual variable.

@matthew, @ocramius Anyway, I understand your points of view, but we can consider not keeping the value in the result of validator.

---

<div class="post-metadata">

**Author:** ![ocramius](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/ocramius/32/23_2.png) [@ocramius](https://discourse.laminas.dev/u/ocramius)\
**Post date:** [October 18, 2017, 9:55pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/26 "2017-10-18T21:55:30Z")

</div>

The value in the result are required to compose error messages and for  
logging purposes.

Also, that’s what you’d pass to the next “layer”: a “validated result”.

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [October 19, 2017, 12:14am UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/27 "2017-10-19T00:14:32Z")

</div>

> [@Seryus](#):
>
> the new InputFilter proposed by Bakura (which seems will be used for 3.0) retains the raw and filtered values.

This is not necessarily true; it’s more than probable we will not use that code base, particularly as it made assumptions about the design of the validation component that are no longer true.

The plan at this point is for input filtering to _also_ be stateless, and follow a similar design to this component: pass values to validate, and receive a result object back.

As @ocramius also notes, retaining the value in the result asked us to pass a single message to loggers, error handlers, etc. without requiring an additional message/argument.

I’m curious why you feel so strongly that we should not do this…

---

<div class="post-metadata">

**Author:** ![Seryus](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/seryus/32/216_2.png) [@Seryus](https://discourse.laminas.dev/u/Seryus)\
**Post date:** [October 19, 2017, 7:08am UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/28 "2017-10-19T07:08:38Z")

</div>

It’s just a suggestion, I’m not saying that we should not do this.

It seems strange to me to retain the raw value in the validator result, as we already have access to it anyway. The exception is, as you pointed, to get the value to compose error messages, but in this case value could be part of the `$this->messageVariables` passed to the constructor of `ValidationFailureMessage`. I’m not aware about how loggers work, I don’t know if they need the value to be treated differently from other messages variables.

Anyway, I got my answer, thanks 🙂

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [January 15, 2018, 4:01pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/29 "2018-01-15T16:01:29Z")

</div>

We may have access to it in the scope in which the validation occurs, but that would then require passing that raw value _and_ the result to any logger/reporter functionality. Passing only the result is far simpler.

---

<div class="post-metadata">

**Author:** ![CarlosEduardo](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/carloseduardo/32/62_2.png) [@CarlosEduardo](https://discourse.laminas.dev/u/CarlosEduardo)\
**Post date:** [January 16, 2018, 1:51pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/30 "2018-01-16T13:51:46Z")

</div>

+1 about Interface and Trait suffixes: _“[…] **consistency with existing components** is likely more important at this time than other concerns.”_

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [January 16, 2018, 2:31pm UTC](https://discourse.laminas.dev/t/rfc-new-validation-component/208/31 "2018-01-16T14:31:10Z")

</div>

This change has already been made, and is reflected in the repository.

[Previous page](https://discourse.laminas.dev/t/rfc-new-validation-component/208.md?page=1)