improvement(DateTime): handle multiple deserialization formats and timezones#39
Conversation
|
I seem to have trouble with both Rector and PhpCS on files I haven't edited here, am I missing something? |
|
seems to be changes in cs fixer and rectorphp. i fixed the errors in #40 |
| if (null !== $format) { | ||
| return $this->templating->renderAssignDateTimeFromFormat($type->isImmutable(), (string) $modelPropertyPath, (string) $arrayPath, $format); | ||
| // todo: remove use of deprecated method {@link \Liip\MetadataParser\Metadata\PropertyTypeDateTime::getDeserializeFormat} | ||
| $formats = method_exists($type, 'getDeserializeFormats') ? $type->getDeserializeFormats() : null; |
There was a problem hiding this comment.
instead of checking for method existence, we can change composer.json to require ^1.2.0 of metadata-parser.
There was a problem hiding this comment.
Looking at this place, it does feel weird: JMS made the choice of making the serialization format the deserialization format as well by default, which is understandable. But the way liip/* is structured, it should be possible to accept datetimes from a variety of formats by default (new DateTime($data)), and output them in a single format. Do you think it would be too bad of a BC break to do that?
There was a problem hiding this comment.
i think there would not be a BC break, because until now we would have errored if there were multiple formats, no? or i misunderstand, it would still be ok if we accept more valid but differently formatted dates than before, i don't see a problem there.
as long as we don't accidentally change the format when we serialize a date, i see no risks in adding more flexibility.
| 'format' => $format, | ||
| 'formats' => array_map( | ||
| static fn (string $f) => var_export($f, true), | ||
| \is_string($formats) ? [$formats] : $formats |
There was a problem hiding this comment.
i would prefer to do that at the top of this method, immediately sanitize the $formats. additionally, we could trigger a deprecation warning when a string is passed instead of an array.
There was a problem hiding this comment.
trigger a deprecation? should that be done with doctrine/deprecations or with a simple trigger_error($message, E_USER_DEPRECATED) ?
There was a problem hiding this comment.
i would do it the same as symfony does: https://github.com/symfony/symfony/blob/6c9107334da9e443a4f64f782a93182ac453bf78/src/Symfony/Component/ErrorHandler/DebugClassLoader.php#L337C18-L337C18
@trigger_error('...', \E_USER_DEPRECATED);
|
thanks a lot for this work! i commented a couple of questions. |
a93acda to
acc5ed8
Compare
16b0fba to
add6517
Compare
|
great! can you please rebase on the 2.x branch so that cs and rector errors not related to your changes go away? then we see if all is fine with the changes. and can you please add an entry to the CHANGELOG.md file that explains the new functionality? we use this for the release notes on github, and users can read the changelog to discover new features. |
Changelog is updated I remember indeed rebasing on the 2.x branch when I picked back up this PR, due to Rector/CSFixer issues, but the issues persisted. I just tried re-pulling the branch just to make sure, but the git history still says my branch is indeed based on the tip of the current One thing to note is, for edit: could it be that I have a different php-cs-fixer configuration? I don't see where it was configured to place empty braces pairs on the same line in my |
|
the thing is that we do not lock a specific cs fixer version, and the latest minor version had some new rules. i am updating in #43 |
c0b9b44 to
b682b31
Compare
dbu
left a comment
There was a problem hiding this comment.
great, thanks a lot for this contribution! and thanks for the patience to get this mergeable.
|
🎉 |
|
there are a couple things in metadata-parser that should be done before releasing. i tried to be minimal to only have the things that need BC breaks, but supporting doctrine attributes instead of annotations would be quite useful for the future too: https://github.com/liip/metadata-parser/issues |
The deserialization generator does not handle timezones for PropertyDateTime, and will throw an exception if the metadata contains any. In addition, with the liip/metadata-parser#44 PR , I've also implemented the handling of multiple deserialization formats.
Here's a small script I've put together for this feature, from the same PR, just with the timezones added
P.S. : I'll be adding more tests laterMore tests have been added for those cases