Skip to content

Move normalizeIdentifiers method to a new Util class IdentifierManager #907

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 20, 2017

Conversation

soyuka
Copy link
Member

@soyuka soyuka commented Jan 12, 2017

Q A
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets none
License MIT
Doc PR none

Better SRP + cleaner code/tests regarding the ItemDataProvider.

@soyuka soyuka requested review from dunglas and teohhanhui January 12, 2017 14:05
*/
public function __construct(ManagerRegistry $managerRegistry, PropertyNameCollectionFactoryInterface $propertyNameCollectionFactory, PropertyMetadataFactoryInterface $propertyMetadataFactory, array $itemExtensions = [])
Copy link
Member

Choose a reason for hiding this comment

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

Problem: this is a BC break...

Copy link
Member Author

Choose a reason for hiding this comment

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

raw

Copy link
Member Author

Choose a reason for hiding this comment

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

why btw? Interface hasn't been impacted or is it because the class isn't "final" and so can be extended?

Copy link
Member

@dunglas dunglas Jan 12, 2017

Choose a reason for hiding this comment

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

It's because if someone initializes this class by himself (and some people including me do) it will break.
This document is a nice reference of what is a BC break or not: http://symfony.com/doc/current/contributing/code/bc.html

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice link! To bad though, this is a nice improvement IMO.

I can make this work without BC by still injecting both metadata factories and calling new IdentifierManager manually in the constructor, not sure that it'd be accepted though.

Copy link
Member

Choose a reason for hiding this comment

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

It's a good solution for now.

Copy link
Member

Choose a reason for hiding this comment

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

Btw, maybe should we make this new class internal as this logic should not be exposed or replaced. Maybe can we just use a trait too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree this could be a trait

Copy link
Member Author

Choose a reason for hiding this comment

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

lol @Simperfit still we don't need the factories in the data provider but they're needed to get the identifiers. What would be the best to inject those?

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's use a trait.

*/
public function __construct(ManagerRegistry $managerRegistry, PropertyNameCollectionFactoryInterface $propertyNameCollectionFactory, PropertyMetadataFactoryInterface $propertyMetadataFactory, array $itemExtensions = [])
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's use a trait.

use ApiPlatform\Core\Metadata\Property\Factory\PropertyNameCollectionFactoryInterface;
use Doctrine\Common\Persistence\ObjectManager;

class IdentifierManager implements IdentifierManagerInterface
Copy link
Contributor

Choose a reason for hiding this comment

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

CompositeIdentifierTrait?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not really related to composite identifiers

@soyuka
Copy link
Member Author

soyuka commented Jan 13, 2017

Trait it is 🕺

@dunglas
Copy link
Member

dunglas commented Jan 13, 2017

👍

@soyuka
Copy link
Member Author

soyuka commented Jan 18, 2017

can we merge this?

use ApiPlatform\Core\Exception\PropertyNotFoundException;
use Doctrine\Common\Persistence\ObjectManager;

trait IdentifierManagerTrait
Copy link
Member

Choose a reason for hiding this comment

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

Can you make it @internal for now?

Copy link
Member Author

Choose a reason for hiding this comment

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

done

@soyuka soyuka force-pushed the move-normalize-identifier branch from 5e66aac to 1f72a9b Compare January 18, 2017 19:50
@dunglas dunglas merged commit fe9ad62 into api-platform:master Jan 20, 2017
@dunglas
Copy link
Member

dunglas commented Jan 20, 2017

Thanks @soyuka

/**
* @internal
*/
trait IdentifierManagerTrait
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think IdentifierManagerTrait is a bad name. CompositeIdentifierTrait makes sense to me, because this is a trait that helps with handling composite identifiers (even when the identifier is not composite).

Or perhaps another, because the "manager" part of IdentifierManagerTrait definitely does not inspire confidence that it is not violating SRP (a manager trait?!).

Copy link
Member Author

Choose a reason for hiding this comment

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

What about IdentifierNormalizerTrait?

@soyuka soyuka deleted the move-normalize-identifier branch March 30, 2017 06:31
teohhanhui added a commit to teohhanhui/api-platform-core that referenced this pull request May 4, 2017
teohhanhui added a commit to teohhanhui/api-platform-core that referenced this pull request May 5, 2017
teohhanhui added a commit to teohhanhui/api-platform-core that referenced this pull request May 15, 2017
dunglas added a commit that referenced this pull request May 15, 2017
hoangnd25 pushed a commit to hoangnd25/core that referenced this pull request Feb 23, 2018
…fier

Move normalizeIdentifiers method to a new Util class IdentifierManager
hoangnd25 pushed a commit to hoangnd25/core that referenced this pull request Feb 23, 2018
hoangnd25 pushed a commit to hoangnd25/core that referenced this pull request Feb 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants