Skip to content
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

Rewrite Translatable/Translation to use Interfaces instead of Traits #387

Closed
wants to merge 2 commits into from

Conversation

akerouanton
Copy link
Contributor

@akerouanton akerouanton commented May 2, 2018

This is PR #322 rebased on current master branch and with minor fixes. Credits go to @lemoinem

Left to do:

  • Update readme and upgrade guide
  • Implement a compatibility layer to smooth transition from trait to interface (in a separate PR)

@akerouanton akerouanton requested a review from soullivaneuh May 2, 2018 10:59
@lemoinem
Copy link
Contributor

lemoinem commented May 2, 2018

Thanks @NiR- for the follow up and the credits. Sorry I didn't have the time to do the follow up.
I'm happy to see this move forward and getting merged!

@akerouanton
Copy link
Contributor Author

No worries, actually we were not really active on this repository in the previous months, too.

@@ -43,11 +43,11 @@ public function getNewTranslations()
/**
* Adds new translation.
*
* @param Translation $translation The translation
* @param TranslationsInterface $translation The translation

Choose a reason for hiding this comment

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

Should be TranslationInterface (singular)

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

'Knp\DoctrineBehaviors\Model\Translatable\Translatable',
'Knp\DoctrineBehaviors\Model\Translatable\Translation',
array('Knp\DoctrineBehaviors\Model\Translatable\Translatable', 'Knp\DoctrineBehaviors\Model\Translatable\TranslatableProperties'),
array('Knp\DoctrineBehaviors\Model\Translatable\Translation','Knp\DoctrineBehaviors\Model\Translatable\TranslationProperties',),

Choose a reason for hiding this comment

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

Maybe it could be good to also have a test in case where a non array value (eg an object) is passed here instead of an array ?

*
* @return $this
*/
public function setTranslatable($translatable);

Choose a reason for hiding this comment

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

Can you typehint the parameter ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added it but I'm not sure if I should add other missing types (notably return types) in this PR or create a dedicated one, mostly because I would have to modify traits (I wouldn't make the diff cluttered). WDYT?

Choose a reason for hiding this comment

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

Thanks, yes I agree that return typehints should be added in a separate PR :)

@@ -68,11 +68,11 @@ public function loadClassMetadata(LoadClassMetadataEventArgs $eventArgs)
return;
}

if ($this->isTranslatable($classMetadata)) {
if ($this->requiresTranslatableMapping($classMetadata)) {

Choose a reason for hiding this comment

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

The previous isTranslatable name was more understandable IMHO, and also in a way more accurate as requires could make think of a state awareness. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did the change thinking the old names were better, but then I realized that both method have a different meaning, even if they do the exact same thing. That is, an entity can implement TranslatableInterface an be a translatable, but still not require automatic mapping (that's what we try to determine by detecting if the entity uses some specific traits).

Now that said, I realize we should rather get rid of that trait detection, and just automatically add doctrine mapping as it's done right now (thus, manual mapping won't be overwritten). But the compatibility layer needed to give a smooth upgrade plan to users would be a bit more complex).

$this->mapTranslatable($classMetadata);
}

if ($this->isTranslation($classMetadata)) {
if ($this->requiresTranslationMapping($classMetadata)) {

Choose a reason for hiding this comment

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

same here about the name

@TomasVotruba
Copy link
Contributor

Covered by #442

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants