How to handle multiple model behaviors

[wurst-hans]

Currently, I'm building a minimal bootstrap project as base for all my other projects. I thought about models behavior now. Additionally to the SoftDelete and Timestampable I want to create a behavior which logs changes on model columns to a dedicated table.

The best approach, I think, is to create something like traits for each behavior that can be added to every model if required. But I don't want to use traits like mentioned in Phalcon doc, which use events themselves. My traits should be recognized on initialization and added with $this->addBehavior();, for example:

use Phalcon\Mvc\Model;
use Phalcon\Mvc\Model\Behavior;

class HistorizeData extends Behavior {
    public function notify() {...}
}

trait HistorizeTrait {
    protected function initHistorization() { return new HistorizeData(); }
}

class BaseModel extends Model {
    public function initialize() {
        /*
         * what to do here?
         * something like:
         */
        if (method_exists($this, 'initHistorization')) {
            $this->addBehavior($this->initHistorization());
        }
    }
}

class CustomModel extends BaseModel {
    use HistorizeTrait;

    public function initialize() {
        parent::initialize();
        // additional settings
    }
}

I think, having many models it can improve flexibility and configuration of models a lot when you just have to add multiple traits for enabling a (real) behavior.
Can anyone point me into right direction how to achieve this? Does the above make sense? Sure, for every new behavior (i.e. trait) the base model has to be extended. How can it be improved?

EDIT: I've seen class_uses() right now, which can be used...

[diplopito]

Hi Hans, just a couple of untested ideas:

1. If you add the behaviour in the base model it shouldn't be necessary to use it as a trait in the inherited models (?);
2. Have you tried to implement the logger with the aferUpdate or afterCreate events?

[diplopito]

Which examples do you have in mind? Another option is to create a dedicated logger in the DI and call it where you want it (you escape the trait like this)

[wurst-hans]

In Phalcon you can setup a MVC model without specifying any properties or methods (getter/setter). This leads to two questions.

1. Do I want to access properties by snake case or camel case, i.e. echo $robots->model_number; or echo $robots->modelNumber;
2. Do I want to have magic getters/setters, i.e. echo $robots->getModelNumber();

The magic setters in Phalcon documentation are different from the setters I mean, because, by default it's not possible to call $robots->setModelNumber('xyz');. I want to be able to set this behavior for each model individually, ideally by including a trait simply.

The historizing I mentioned, may be enabled for some specific models only. Also, I've added a simple function for enabling cache key in find() and findFirst() without having to provide it in parameters explicitly.

And by simply adding a trait to my model, I can omit overwriting initialize() even for such simple things like useDynamicUpdate(). The only drawback is, that each trait has to have a boot-up method with unique name that is executed inside initialize() of base model. Ideally, every trait should have a boot-up method with fixed name, but that conflicts when using multiple traits.

[diplopito]

Why use multiple traits for saving the history?

[wurst-hans]

I think, there is a misunderstanding. I have written different behaviors for my model classes.
One is a behavior to log model changes (afterUpdate) to a dedicated table. And to enable this behavior (and the other ones) I'm just looking for a solution to include a trait into my project models, without having to write an initialize() method all the time. The intention is to enable different behaviors for different models as easy as possible. And just using traits is as easy as possible. The problem is, when different behaviors use the same event (i.e. afterUpdate), because traits in PHP cannot have same methods.
It's just a thing of comfort. For the moment, each trait (more precisely each behavior) has a unique "boot-up" method. So only my base model class has an initialize() method to search for any included trait boot-up method and finally attach a behavior this way. I was just wondering, if there is a best practise for this abstract way of adding behaviors to models.

[diplopito]

Maybe it would help if you share a couple of samples of the traits and behaviors that you have implemented for the models. My impression is that the traits could be abstracted in a QueryLoggerService.