You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.
This issue describes a problem with the ZF2 input filtering that I would like to be fixed in the future ZF3 solution for input filtering.
Our preferred solution for building input filters in our application is by using config arrays and generating them through the input filter factory class. We often have nested input filters (for validating field-sets or nested resources). To reuse input filters inside other configs, when using field-sets or when handling complex nested resources it is necessary to add a type field to the config as follows:
Now comes the issue...
It is not uncommon to use the field type for data, in our case we have type as a property for several of our resources. This breaks the whole pattern of configuring our input filters with arrays. If we use the type field for input we can no longer set the input filter class in the config...
I think it is a design mistake to use a key with a common name like type at the same level as the input fields (properties) for setting the class in the config array.
A solution could be to use a more specific key to make it less likely to have conflicts with input field names, for example input_class, or maybe even input_type.
Probably it would even better to move the type field one level up in the config, so conflicts will never be an issue. The config could for example look like this:
I have no idea about what the design for ZF3 input filtering looks like, but I just want to make sure that this issue would be solved in case it might be done similarly in ZF3.
The text was updated successfully, but these errors were encountered:
This issue describes a problem with the ZF2 input filtering that I would like to be fixed in the future ZF3 solution for input filtering.
Our preferred solution for building input filters in our application is by using config arrays and generating them through the input filter factory class. We often have nested input filters (for validating field-sets or nested resources). To reuse input filters inside other configs, when using field-sets or when handling complex nested resources it is necessary to add a type field to the config as follows:
The factory will recognize the
type
key and sets it as the$class
to use during building of theInputFilter
. So now we can make our input filter like this:You can even another class as long as the class implements the
InputFilterInterface
Now comes the issue...
It is not uncommon to use the field
type
for data, in our case we havetype
as a property for several of our resources. This breaks the whole pattern of configuring our input filters with arrays. If we use thetype
field for input we can no longer set the input filter class in the config...I think it is a design mistake to use a key with a common name like
type
at the same level as the input fields (properties) for setting the class in the config array.A solution could be to use a more specific key to make it less likely to have conflicts with input field names, for example
input_class
, or maybe eveninput_type
.Probably it would even better to move the type field one level up in the config, so conflicts will never be an issue. The config could for example look like this:
I have no idea about what the design for ZF3 input filtering looks like, but I just want to make sure that this issue would be solved in case it might be done similarly in ZF3.
The text was updated successfully, but these errors were encountered: