[NFR]: Forms should transform "" to NULL unless explicitly told not to about phalcon

[scrnjakovic]

Actually, this is more NFR as this is obviously due to the fact that all POST/GET values are strings, with the exception of array of course.

What I propose we do is have Form::bind turn empty strings into null by default before assigning it to the model. For those who, for whatever reason, want empty strings in their databases, they can allow it with something like

$form->allowEmptyStrings(
    [
        'fieldName'
    ]
);

or

$field = new Text(
    'field',
    [
        'allowEmptyString' => true
    ]
);

[niden]

@scrnjakovic Looking at this I have one concern. How would Phalcon know that an empty string is indeed an empty string vs. a null? There will be instances where the POST will be an empty string and this would be what I might want to add in the database vs a null.

Thoughs?

[scrnjakovic]

@niden Without getting into a discussion on why would one want empty strings in a database, I suppose there is a valid use case somewhere, I still think those cases are quite rare or at least less common than having nullable column for when there is no value. So my idea was to treat all empty strings as nulls unless field is explicitly flagged to accept empty strings.

[zsilbi]

I am not a fan of storing empty strings either, but reasonable use cases max exist.
It's not an example I'd use personally, but in view you could decide to print the stored content if it's a string (even if it's empty), or use an alternative method to gather the content when it's null.

Filters can be used on Form elements, so I'd maybe write a Filter which returns null if the input is empty then set it to the elements I need.
If it's required on all the elements I'd override Form::add() in the Form object.

[niden]

@zsilbi I like this approach better because it extends the forms even more for developers.

We already have Validators for forms (valid/not valid). We can also attach Filters or Transformers or Decorators so that we can achieve this transformation

I will move this to the 4.1 release because this requires significant work.

[scrnjakovic]

Yeah, I don't mind that approach, I just advocate NULL being default and empty string optional. That makes more sense to me.