Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Better handling of observer settings
  •  I've recently been dabbling with ORM observers and have found them to be very useful. However it seems weird to me that the established way to retrieve the observer settings on a model is to use $props = $class::observers(get_class($this));  and set properties on the observer class from there. Specifically, I've run into an issue where if I use the same observer more than once on the same model, with different settings, I can't get their settings using the above method.

    Wouldn't it make more sense if in the \Orm\Model's observe method, the settings were passed to the instance method of \Orm\Observer, and then in turn passed to the constructor for the specific observer class? (Sorry for the weird formatting, I don't know how to display code on these forums)


    Line 1522 of \Orm\Model:

    call_user_func(array($observer, 'orm_notify'), $this, $event, $settings);

    And then \Orm\Observer:
    public static function orm_notify($instance, $event, $settings = array())
    $model_class = get_class($instance);
    if (method_exists(static::instance($model_class), $event))
    static::instance($model_class, $settings)->{$event}($instance);

    * Create an instance of this observer
    * @param string name of the model class
    public static function instance($model_class, $settings = array())
    $observer = get_called_class();
    if (empty(static::$_instances[$observer][$model_class]))
    static::$_instances[$observer][$model_class] = new static($model_class, $settings);

    return static::$_instances[$observer][$model_class];

    Then you could get the settings for each specific observer.
  • The main reason for this is memory usage and performance.

    By maintaining a list at the static level, it only has to be kept once. If you pass it on to the instance, you might duplicate the information thousands of times, which will absolutely have impact.

    Having said that, we are aware of the limitations of the current observer system. In v2, it will be replaced by an event-driven system, using, which is a lot more flexible. We are even thinking about making core functions of the ORM model event driven (like save, delete, etc), which will make it very easy to add functionality to a model (for example soft-delete, or versioning), just by swapping or injecting an event.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion