Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Serializer] Add Support forobject_to_populate in CustomNormalizer#21716

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

chrisguitarguy
Copy link
Contributor

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#21715
LicenseMIT
Doc PRn/a

This pulls a trait out ofAbstractNormalizer with a method to extract the object to populate and adds some tests for it. Then uses that trait in bothAbstractNormalizer andCustomNormalizer so both can support theobject_to_populate key.

@chrisguitarguychrisguitarguy changed the title[Serializer] Add Support forobject_to_populate to CustomNormalizer[Serializer] Add Support forobject_to_populate in CustomNormalizerFeb 22, 2017
$context[static::OBJECT_TO_POPULATE] instanceof $class
) {
$object = $context[static::OBJECT_TO_POPULATE];
if (null !== $object = $this->extractObjectToPopulate($class, $context, static::OBJECT_TO_POPULATE)) {
unset($context[static::OBJECT_TO_POPULATE]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Shouldn't this line be moved in in the trait too?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Would involve passing context by reference into the trait. That's the only reason I didn't do it.

return $context[$key];
}

return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Useless, can be removed.

* @param string $class The class the object should be
* @param $context The denormalization context
* @param string $key They in which to look for the object to populate.
* Keeps backwards compatibility with `AbstractNormalizer`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There is no reason to mention this in the comment IMO.

Copy link

@felipsmartinsfelipsmartinsFeb 24, 2017
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why not?

@dunglas
Copy link
Member

dunglas commentedFeb 24, 2017
edited
Loading

Just asking, what is the use case of this class? I think that it's always better to create custom normalizers (implementing theNormalizerInterface than adding the serialization logic in the class itself.

I would be in favor of deprecating this class now and remove it from Symfony 4.

B-Galati reacted with thumbs up emoji

@chrisguitarguy
Copy link
ContributorAuthor

chrisguitarguy commentedFeb 24, 2017
edited
Loading

Just asking, what is the use case of this class?

In my case, I was interested in using it with a "dumb" dto-like object.

class SomeDtoimplements DenormalizableInterface{// ...}

The idea being to keep everything close together: the normalization, denormalization, and the DTO itself. So basically what you are against :)

I was interested in doing this because I think it's a lot nicer developer experience to keep the normalization/denormalization closer to the object being serialized/deserialized. Easier to understand and catch at a glance. Doesn't require you to register services in the container with a special tag, etc.

B-Galati reacted with thumbs up emoji

@nicolas-grekasnicolas-grekas added this to the3.x milestoneFeb 25, 2017
@fabpot
Copy link
Member

@chrisguitarguy Can you please rebase it so that we can merge it? Thanks. Base should also be changed to 3.4.

And use that trait in `AbstractNormalizer`.
And fallback to the default `new $class();` behavior.
@chrisguitarguy
Copy link
ContributorAuthor

chrisguitarguy commentedSep 27, 2017
edited
Loading

@fabpot rebased onto 3.4. Did you want me to make any of the changes@dunglas suggested?

@fabpot
Copy link
Member

Looks like he approved this PR without any further changes :)

@fabpot
Copy link
Member

Thank you@chrisguitarguy.

fabpot added a commit that referenced this pull requestSep 27, 2017
…ustomNormalizer (chrisguitarguy)This PR was squashed before being merged into the 3.4 branch (closes#21716).Discussion----------[Serializer] Add Support for `object_to_populate` in CustomNormalizer| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#21715| License       | MIT| Doc PR        | n/aThis pulls a trait out of `AbstractNormalizer` with a method to extract the object to populate and adds some tests for it. Then uses that trait in both `AbstractNormalizer` and `CustomNormalizer` so both can support the `object_to_populate` key.Commits-------ec9242d [Serializer] Add Support for  in CustomNormalizer
@fabpotfabpot closed thisSep 27, 2017
This was referencedOct 18, 2017
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@felipsmartinsfelipsmartinsfelipsmartins left review comments

@dunglasdunglasdunglas approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
3.4
Development

Successfully merging this pull request may close these issues.

6 participants
@chrisguitarguy@dunglas@fabpot@felipsmartins@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp