Behaviors in 3.0

[mark_story]

Hi everyone,

I've been starting to think about how behaviors in 3.0 should work, and what sorts of improvements we can make with them. With model's being split into Table and Entity classes, and traits being available some changes are necessary.

I've compiled my thoughts and plans into a wiki page https://github.com/markstory/cakephp/wiki/Behavior-changes

I'd like to get some feedback on the proposal, and specifically about:

* How should validation callbacks be handled? What arguments should they get?

* Should we keep all of the existing behaviors? Are there any outside of the timestamp + counterCache features that should be added?

-Mark

[ADmad]

In the callbacks list "afterFind()" is not listed, is that intentional?

Regarding existing behavior:

* Acl - Can we get rid of it and move required functionality in authenticate/authorize objects?

* Containable - Will it be still needed with the new ORM?

* Translate - It would be needed but hopefully after a total overhaul. Personally i never liked the idea of one row per field in the i18n table.

* Tree - It's pretty useful to keep around.

I don't have any suggestions regarding validation right now.

[José Lorenzo]

I think the proposal looks good but I have a few observations:

* Callbacks should have the parameters swapped. This will go inline with the rest of the framework, as we are now defaulting to passing all event params to listeners.

* Custom finders and magic methods should not receive as first parameter the table object as in 2.x, this would mean that the table instance should be stored in the behavior automatically for easy access.

* We should introduce new callbacks to operate on a bath level for beforeSave and afterSave. I often do more things using batches than working directly with each row.

I think there should be no validation callbacks at all, in 2.x they were abused to implement setters or to do actual validation. This had several problems in my view, one is that setters would not be triggered if anyone skipped the callbacks or set validation to false, and the other is that it would break the validation chain.

Setters can be placed easily in the entity class, and validation should be done using the validation API.

@ADmad the omission of afterFind is intentional. Any record level change should be done in the entity. Any aggregation can be done using the map - reduce API

I agreed with ADMad selection of behaviors. I would personally like a default implementation of a SoftDelete behavior.

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ravage84]

This forces developers to namespace settings and properties.

I Like that.

Should we keep all of the existing behaviors?

How about keeping none? I'm may be a bit extreme but I think all of them could be CakePHP project managed plugins.
That would keep the framework slim but because of Conposer it's easy and fast enough to implement them for your project.

I would personally like a default implementation of a SoftDelete behavior.

If we do have built-in behaviors this one should be in there.
Makes CakePHP more enterprisy (but in a good way for once) ;-P

Containable

To my understanding, this one is not a real behavior but some kind of "externalised" core functionality.
It's good this will become part of the core now.
But we should keep cautious about doing the same mistake for 3.0 with some other functionality.

The $actsAs property will not be supported.

Very good!
The less we rely on properties to do such stuff, the better I think.
It will certainly lead to some slightly more code than now and I'm pretty sure some people will bemoan "the good ol' days" but it's for their better.

In the case where two behaviors provide the same method or finder an exception will be thrown when the second behavior is attached.

Fair enough, just put up a warning note in the CookBook 3.0 section "How to Write a Behavior" that people use unique enough names for the finders.

[mark_story]

Other callbacks all receive the event object as the first parameter, and any additional arguments after. Where were the arguments incorrect?

Point taken about the mixin methods. Behaviours needing the table object can store a reference in their constructor. This change will cause more churn internally, but I think it will be a good change overall.

Containable behaviour will be removed, I think AclBehavior is useful if we are keeping the same dbacl feature. If not it really has no place.

SoftDelete would be a nice addition. If we could adopt and tweak an existing implementation, that would be better than starting over.

How would batch events for beforeSave work? Right now we don't have ant events for batch operations.

-Mark

On Sunday, 20 October 2013 08:22:28 UTC-4, José Lorenzo wrote:
> I think the proposal looks good but I have a few observations:
>
>

> * Callbacks should have the parameters swapped. this will go inline with the rest of the framework, as we are now defaulting to passing all event params to listeners.

[José Lorenzo]

I was under the impression that listeners received the parameters first and the event object as last argument, if that is not the case then it's all good :)

Batch operation would be triggered for the saveAll method, it will receive the array of entities to save.

[mark_story]

The callbacks in components + helpers receive the event as the first argument, and passed data is splatted in afterwards.

I think that validation callbacks are useful in principal, and would be something we'd want to continue supporting. An alternative option is to have Behaviors add their required validation rules to the Table when the behavior is connected. For example a behavior's constructor could call `$table->validator()->add()`. I think this is a bit less flexible than before/after validation callbacks though.  I don't think we should remove them because people use them wrong. If we did that, we'd have no callbacks as I'm sure someone has abused every callback the framework provides.

I have tried to update the wiki page to address the comments so far. Great discussion so far.

-Mark

[rchavik]

On Sunday, October 20, 2013 11:52:13 PM UTC+7, Ravage84 wrote:

Should we keep all of the existing behaviors?

How about keeping none? I'm may be a bit extreme but I think all of them could be CakePHP project managed plugins.
That would keep the framework slim but because of Conposer it's easy and fast enough to implement them for your project.

I would prefer to have them in core just for the reason of having it more visible.  Core would have more eyeballs looking at them.
 

I would personally like a default implementation of a SoftDelete behavior.

If we do have built-in behaviors this one should be in there.
Makes CakePHP more enterprisy (but in a good way for once) ;-P

I would argue that enterprise would want permission management, audit trails etc.  So, Acl, Trackable/WhoDunIt, Auditable etc
would be 'enterprisey'. Thus we can't move Acl out of core :p

The $actsAs property will not be supported.

Very good!
The less we rely on properties to do such stuff, the better I think.

+9001

[Saleh Souzanchi]

hi,'m Sorry, I could not write English very well to offer myself.
So I created a 3 page slide. ​

 CakePHP 3 Behavior -my Proposal

​
For all the hard work to develop of CakePHP 3 thank you and team.

     Best Regards
   Saleh  Sozanchi
 * * * * * * * * * * * * *

Mobile : +98 918 111 7209

Phone : +98 811 823 4448

http://soozanchi.ir
http://cakephp.ir

[José Lorenzo]

Fair enough, let's keep the callbacks then.

[mark_story]

Thanks for the slides, I think diagrams are a great way to show ideas when language is a barrier.

Won't registering tasks on each save operation get expensive if there are 10+ models being saved?  Registering all the callbacks once saves on repeating this work for each save operation. I think having 2 callback methods for each callback might get a bit complicated given that model has 5 events.

-Mark

[mark_story]

I've got a pull request with the first stage of work for this up at https://github.com/cakephp/cakephp/pull/2207

-Mark