Feature #37294

Property converters should allow NULL results

Added by Carsten Bleicker over 9 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Could have
Category:
Property
Target version:
-
Start date:
2012-05-19
Due date:
% Done:

0%

Estimated time:
PHP Version:
Has patch:
No
Complexity:

Description

Can someone explain me why the DateTimeConverter returns a Validation Error and does not throw an exception? (Line #122)
All other Converters throwing exceptions only. shouldnt the validation only be a part of @FLOW3\Validate notations?


Files

DateTimeConverter.php (6.88 KB) DateTimeConverter.php Carsten Bleicker, 2012-05-19 11:52

Related issues

Related to TYPO3.Flow - Bug #36996: DateTimeConverterClosed2012-05-09

Actions
Related to TYPO3.Flow - Bug #49566: NULL source values are not handled correctlyNewAdrian Föder2013-07-02

Actions
#2

Updated by Adrian Föder over 9 years ago

Hi Carsten,

a good question; allow me to point to this commit: http://git.typo3.org/FLOW3/Packages/TYPO3.FLOW3.git?a=commit;h=b47d1c61aaaf67c6d9c3379d87fe132ff7bded80
It might explain it very well.
If you have further questions don't hesitate to ask :)

#3

Updated by Carsten Bleicker over 9 years ago

thanks adrian,
but thats exactly the point wich describes a unexcepted behaviour for me but its not only a unexpected datetimeconverter behavious.
lets say f.e. i want to have a start and a stop property. both could be null to definine a runtime of an object.
if the converter returns allways a valid datetime i am not able to set some properties to NULL.
in my opinion any converter should return NULL if converting fails or the source is an empty string.
f.e. also the float or integer converter. In this case no exception cant be thrown in any Converter because NULL
is possible. But i aggree that exceptions SHOULD be thrown if the property isnt nullable.
to work with exceptions in case of not allowed NULL values i suggest to extend the behavior of subproperty mapping of
the objectConverter f.e. any property converting should be able to analyze its annotations. so the converter is able to to the following:

if class annotated with @ORM\Column(nullable=true) the converter is able to convert to null and it does not throw an exception.
if class isnt annoted as nullable it throws exceptions.

what do you think?

in my opinion there is realy a need to allow null resulting converters.

kind regards
carsten

#4

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns
#5

Updated by Karsten Dambekalns over 9 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from DateTimeConverter to Property converters should allow NULL results
  • Status changed from Accepted to New
  • Assignee deleted (Karsten Dambekalns)
#6

Updated by Adrian Föder over 8 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Carsten Bleicker

Carsten,

I don't fully understand that now, because some TypeConverters already return NULL in the cases you've mentioned (Integer- and FloatConverters for example have

        if ($source === NULL || strlen($source) === 0) {
            return NULL;
        }

So it's not a design problem of the mapping framework, but of particular converters, is that correct? Could you name the converters where you think NULL should be returned silently?

#7

Updated by Bastian Waidelich over 7 years ago

  • Status changed from Needs Feedback to Closed

For the record: Adrian is correct, if the model supports NULL-values (nullable=true and allow NULL in the setters) this should work just fine.
Closing due to missing feedback. Feel free to comment or re-open!

Also available in: Atom PDF