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

Add TableEventsTrait #18008

Open
wants to merge 6 commits into
base: 6.x
Choose a base branch
from
Open

Add TableEventsTrait #18008

wants to merge 6 commits into from

Conversation

bancer
Copy link
Contributor

@bancer bancer commented Nov 1, 2024

Explicitly define all model callbacks. See the discussion in #17990

@bancer bancer marked this pull request as ready for review November 22, 2024 12:05
@@ -3204,16 +3205,6 @@ public function implementedEvents(): array
'Model.beforeRules' => 'beforeRules',
'Model.afterRules' => 'afterRules',
];
$events = [];

foreach ($eventMap as $event => $method) {
Copy link
Member

Choose a reason for hiding this comment

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

Isnt this removing the opt in part of it?

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 don't understand your question but this code is unnecessary anymore because all events listed in $eventMap are implemented so $eventMap and $events at the bottom are the same.

Copy link
Member

Choose a reason for hiding this comment

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

I was just kind of thinking that the trait could stay opt in
Not every table might need them anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With this implementation it is up to the user if she wants to implement the callbacks. If not implemented in the user code then empty callbacks are called. So you can say that they are still opt-in. The user is not forced to implement them.

Copy link
Member

@ADmad ADmad Nov 22, 2024

Choose a reason for hiding this comment

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

This foreach needs to stay since we want the trait usage to be opt-in. I already mentioned in the other PR that always having the methods prevents one from typing the $entity argument with a concrete entity class.

Copy link
Member

Choose a reason for hiding this comment

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

Is phpstan also on board here?
With the overwrite?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

An example of the fatal error: https://onlinephp.io/c/f4e51

Copy link
Member

Choose a reason for hiding this comment

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

It will throw an error if the signature is changed in the child class.

So if were to have this trait, it would have to be included in each table class separately and not Table (which can be done when baking).

Would have to check if static analyzers/IDEs complain if you override trait methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you suggest to remove use TableEventsTrait; from the Table class?

Copy link
Member

Choose a reason for hiding this comment

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

Yes

@dereuromark
Copy link
Member

dereuromark commented Nov 22, 2024

I must say I like the interface approach more.
You can either implement the interface with all (ModelEventsInterface) or a concrete one (e.g. ModelBeforeSaveInterface).
This way it is clear for IDE to give you Autocomplete for setup of those methods, for usage.
And if u don't need it those are not added for fun.

The trait could still be there as fallback. But not how about it being present by default.

src/ORM/TableEventsTrait.php Outdated Show resolved Hide resolved
@@ -3204,16 +3205,6 @@ public function implementedEvents(): array
'Model.beforeRules' => 'beforeRules',
'Model.afterRules' => 'afterRules',
];
$events = [];

foreach ($eventMap as $event => $method) {
Copy link
Member

Choose a reason for hiding this comment

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

https://3v4l.org/OTRMDh

Seems I am mistaken, PHP seems to be lenient when overriding trait methods.

@asgraf
Copy link

asgraf commented Nov 25, 2024

* @param \Cake\Event\EventInterface<\Cake\ORM\Table> $event Model event.

shoud be replaced with

* @param \Cake\Event\EventInterface<\Cake\Datasource\RepositoryInterface> $event Model event.

this would allow to cleanly reuse this trait in muffin/webservices

@ADmad
Copy link
Member

ADmad commented Nov 25, 2024

@asgraf This trait is under the ORM package, so \Cake\Event\EventInterface<\Cake\ORM\Table> is accurate. Widening the type would mean again having to use inline annotations.

@dereuromark
Copy link
Member

dereuromark commented Nov 25, 2024

Even with \Cake\ORM\Table you need to use the concrete type as docblock annotation though.
Which is usually fine if tooling based automation support is given.

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.

4 participants