Property converters should allow NULL results
|Priority:||Could have||Due date:|
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?
|related to TYPO3.Flow - Bug #36996: DateTimeConverter||Closed||2012-05-09|
Updated by Adrian Föder about 1 year ago
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 :)
Updated by Carsten Bleicker about 1 year ago
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.
Updated by Karsten Dambekalns 11 months ago
- Status changed from New to Accepted
- Assignee set to Karsten Dambekalns