Feature #37294
Property converters should allow NULL results
| Status: | Closed | Start date: | 2012-05-19 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assigned To: | Carsten Bleicker | % Done: | 0% |
|
| Category: | Property | |||
| Target version: | - | |||
| PHP Version: | Complexity: | |||
| Has patch: | No |
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?
DateTimeConverter.php
(6.9 kB)
Related issues
History
#1 Updated by Carsten Bleicker about 3 years ago
- File DateTimeConverter.php added
#2 Updated by Adrian Föder about 3 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 about 3 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 about 3 years ago
- Status changed from New to Accepted
- Assigned To set to Karsten Dambekalns
#5 Updated by Karsten Dambekalns about 3 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
- Assigned To deleted (
Karsten Dambekalns)
#6 Updated by Adrian Föder about 2 years ago
- Status changed from New to Needs Feedback
- Assigned To 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 1 year 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!