-
-
Notifications
You must be signed in to change notification settings - Fork 922
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
Move normalizeIdentifiers method to a new Util class IdentifierManager #907
Conversation
*/ | ||
public function __construct(ManagerRegistry $managerRegistry, PropertyNameCollectionFactoryInterface $propertyNameCollectionFactory, PropertyMetadataFactoryInterface $propertyMetadataFactory, array $itemExtensions = []) |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 = []) |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CompositeIdentifierTrait
?
There was a problem hiding this comment.
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
Trait it is 🕺 |
👍 |
can we merge this? |
use ApiPlatform\Core\Exception\PropertyNotFoundException; | ||
use Doctrine\Common\Persistence\ObjectManager; | ||
|
||
trait IdentifierManagerTrait |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
5e66aac
to
1f72a9b
Compare
Thanks @soyuka |
/** | ||
* @internal | ||
*/ | ||
trait IdentifierManagerTrait |
There was a problem hiding this comment.
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?!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about IdentifierNormalizerTrait
?
…fier Move normalizeIdentifiers method to a new Util class IdentifierManager
…1014 Backport api-platform#1014 (also includes api-platform#907)
Better SRP + cleaner code/tests regarding the ItemDataProvider.