[DX][Validation] Text/StringValidation #11875
Comments
|
@peterrehm why not using the Regex constraint for your use case ? |
|
@stof This is what I am using currently. However I think this might be an even more common use case where we could avoid errors the developers are experiencing. I just wanted to discuss if this makes sense and if we can think about other usecases. |
|
Well, a Text constraint forbidding some configurable chars would either be a duplicate of Regex, or a less powerful version of it. I don't really see the need for it. |
|
Sure it is a duplicate just to ease the use. I mean the double whitespaces are domain specific but usually if you have a simple string there should not be a line break. It was just an idea to make life easier for developers. |
|
I think the disadvantage of the Regex constraint is that a lot of developers are not catching what is actually happening. This reduces readability. On the other side an /**
* @var string firstName
*
* @ORM\Column(type="string", length=255, nullable=true)
* @Assert\Regex(pattern="/(\s\s)|(\n)/", match=false)
*/
private $firstName;
/**
* @var string lastName
*
* @ORM\Column(type="string", length=255, nullable=true)
* @Assert\Regex(pattern="/(\s\s)|(\n)/", match=false)
*/
private $lastName;What I could consider is wrapping some common patterns the following way: /**
* @var string lastName
*
* @ORM\Column(type="string", length=255, nullable=true)
* @Assert\Text(newLine = false, doubleWhiteSpaces = false)
*/
private $lastName;You immediately see what is happening and this would improve the developer experience. |
|
Well, the issue is that people will then ask us to add more and more stuff in this constraint., making it unmaintainable. so I'm -1 for adding it in core (nothing prevents you to add it in your own project though). @symfony/deciders what do you think about this ? |
|
@Tobion the URL regex is totally crazy, and it is a well defined need. On the other hand, this suggest providing a constraint with multiple behaviors which can each be defined with very simple regexes. thus, it could even be confusing. what would |
|
We didn't discuss the syntax yet, it could also be |
|
@Tobion but then, we would end up with tons of such constraints, because everyone would request their own variations. and this would make the builtin constraints a mess |
|
Well I just wanted to start the discussion. It could be |
|
I'm just saying we probably need some sort of text validation anyway. See ##4102 |
|
I think no developer would search for an existing constraint that prevents newlines or double whitespaces. At least for me, this is not something that I expect a framework to provide if there's a constraint for validating regexes available. The same is not true for URLs, IBANs, credit card numbers etc. There the algorithm is so complex that I definitely would try to find an existing validator first before coding it myself. Consequently, I don't think it makes sense to add this to core, because nobody would use it. If you want to use such specialized constraints in your own application/dev team, just add them yourselves (you just need to override |
|
I have it working on my side. Just thought this would make it consistent. In a text field you should never have a new line. |
|
I suggest you to propose a constraint |
We do have the form types
textandtextareaand in Doctrine the field typestextandstring.If you use a string/text you usually expect some data but not special characters like a line feed.
This is no problem if you use the form component since you cannot enter a line feed in the input field.
If you however develop an API then you might get such unwanted characters in e.g. the name or
the street.
Should we add a validation constraint Text? It could have some defaults to disallow some special characters and options to customize that behavior?
With this we can support the developer to have a more consistent database without the hassle of adding an Regex validator.
I think at least double spaces and line breaks should be invalidated. I was using for this
/(\s\s)|(\n)/so far.What do you think - Does this make sense? What should be invalidated?
The text was updated successfully, but these errors were encountered: