[phpnode]

I was wondering how events will work in 2.0, the current implementation requires quite a lot of boiler plate code (beforeSave(), onBeforeSave()). It might be better to approach events partly in the same way jQuery does

$model = new User;
$model->on("beforeSave", function($event) { $event->isValid = false; } );
// or
$model->on("beforeSave", array("myClass", "myMethod"));

// in the save method
if (!$this->trigger("beforeSave", array("someParam" => "someValueToBePassedToEachEventHandler")) {
    return false
}

This approach considerably reduces the boiler plate, and i don't really see any disadvantages, it also means that you can create new events and listen for them on the fly, without having to change the component's code. The only problem is how to document the events. Perhaps we could use a php doc tag in the class definition:

/**
 * @event beforeSave invoked before a record is saved
 * @event afterSave invoked after a record is saved
 */

[PoL]

This will also allow to use "namespaced" events. For example

$model->on("beforeSave.edit", function() {});
$model->on("beforeSave.create", function() {});

But this also requires a pool of events (per object??)...

Interesting....

[phpnode]

it would also be interesting to allow application wide events, that are invoked after the local events fire, so you could do something like:

Yii::app()->onGlobal("CActiveRecord", "beforeSave", function($event) { echo "This is triggered before any model saves"; });

[qiang]

One of the main reasons for the current event design (i.e. using an on-method to declare an event) is to make event declaration more explicit and better documented (such as what the event parameter would be). And because of this explicit declaration, it also allows events to be bound like a property (i.e. you can use configuration array to initialize a component).

Event binding should be similar here:

// your version
$model->on("beforeSave", function($event) { $event->isValid = false; } );
// current Yii version
$model->onBeforeSave = function($event) { $event->isValid = false; } ;

@PoL: What is the benefit of having namespaced events?

[samdark]

@Qiang, I believe he's talking about signal-slot model where you can use events w/o declaring these and just calling Event::raise('some.name', $arguments) and components are using Event::subscribe('some.name', function($arguments){…}). So it's quite different.

@everyone, here's a good overview of common component interaction methods including different ways to bind/handle events: http://blog.ircmaxel...ins-in-php.html

[PoL]

@qiang: May be an extension can only react to events declared by that extension only. Declaring and raising events with it's own namespace.

[phpnode]

@qiang - you could still allow this, in a slightly different way:

$config = array(
    "class" => "myClass",
    "eventHandlers" => array(
        "beforeSave" => function ($event) { foo(); },
        "afterSave" => function ($event) { bar(); },
    )
);
$component = Yii::createComponent($config);

$component->on("beforeSave", function($event) { echo "before save"; });
$conponent->eventHandlers["afterSave"] = function($event) { echo "after save"; });

The main benefit is that we can add new events to existing classes, without having to edit their source or extend them.

[Rodrigo Coelho]

phpnode, on 09 March 2012 - 11:43 AM, said:

The main benefit is that we can add new events to existing classes, without having to edit their source or extend them.

Maybe I didn't get it, but here's my question anyway: if you add an event to a class without editing or extending it, where/how is the event raised?

[qiang]

@phpnode: could you please explain the use cases that would need to add new events to existing classes?

[phpnode]

mentel, on 09 March 2012 - 01:11 PM, said:

Maybe I didn't get it, but here's my question anyway: if you add an event to a class without editing or extending it, where/how is the event raised?

Via a behavior, or from another event (beforeSave could raise beforeRegister on a user model if the user model is new), or from elsewhere in your application. Behaviors are the main use case I think.

[qiang]

Thanks for your explanation. I will consider your suggestion.

Namespaced events seem to be only meaningful for global events. I'm not sure whether or not we need global event yet.

[Rodrigo Coelho]

phpnode, on 09 March 2012 - 01:46 PM, said:

Via a behavior, or from another event (beforeSave could raise beforeRegister on a user model if the user model is new), or from elsewhere in your application. Behaviors are the main use case I think.

Understood. And interesting.

phpnode, on 09 March 2012 - 01:46 PM, said:

or from elsewhere in your application

But, in this case, I don't think that the event is indeed of the class it's been attached to.
If another class is raising the event, shouldn't the event be of this class?

[samdark]

@phpnode was your suggestion inspired by backbone.js?

[phpnode]

@samdark not backbone specifically, they follow a similar convention to jQuery (or jQuery follows them, I'm not sure which came first), but I think this approach, and the syntax: on(), off(), trigger() are quite common, and self explanatory.

[yiqing95]

qiang, on 09 March 2012 - 02:01 PM, said:

Thanks for your explanation. I will consider your suggestion.

Namespaced events seem to be only meaningful for global events. I'm not sure whether or not we need global event yet.

@qiang : it 's very useful , like jquery 's global ajax event . we can listen the global event to make sure some functionality(similar functionality) handling go together but scatter to everywhere .

by the way i think it 's useful too introduce another event mechanism as symfony ' event dispatcher (don't need declare the event first(pseudo code ) : $eventDispatcher->raiseEvent('anyStringAsEventId',array(../*eventObj or some customer data */)); you should register your eventListener before the raiseEvent : $eventDispatcher->listen('someEvent',array(/*php callable here */)) ; another way is search the event listener in raiseEvent method ,thus we can raise any event in any module ,listening event is the same .when search the event listener we should obey some convention eg: events dir for listening event from anther modules ).

[qiang]

I have implemented the proposed new event system in 2.0. Below are some usage examples:

// attach an anonymous function to the 'click' event
$button->on('click', function($event) { ... });
// trigger the 'click' event
$button->trigger('click', new Event($this));
// detaches $callback from 'click'
$button->off('click', $callback);
// returns event handlers of 'click' as a vector object so that we can manipulate it
$handlers = $button->getEventHandlers('click');

It is also possible to attach an event handler in a configuration array:

$this->widget('Button', array(
    'name' => 'submit',
    'on click' => function($event) {...}
));

Other proposals are not implemented until we see enough evidence they are useful.

[phpnode]

qiang, on 27 March 2012 - 10:47 PM, said:

I have implemented the proposed new event system in 2.0. Below are some usage examples:

// attach an anonymous function to the 'click' event
$button->on('click', function($event) { ... });
// trigger the 'click' event
$button->trigger('click', new Event($this));
// detaches $callback from 'click'
$button->off('click', $callback);
// returns event handlers of 'click' as a vector object so that we can manipulate it
$handlers = $button->getEventHandlers('click');

It is also possible to attach an event handler in a configuration array:

$this->widget('Button', array(
    'name' => 'submit',
    'on click' => function($event) {...}
));

Other proposals are not implemented until we see enough evidence they are useful.

Great news, thanks!

[Jaggi]

qiang, on 27 March 2012 - 10:47 PM, said:

It is also possible to attach an event handler in a configuration array:

$this->widget('Button', array(
    'name' => 'submit',
    'on click' => function($event) {...}
));

Other proposals are not implemented until we see enough evidence they are useful.

could we drop the on bit in the widget array to make it simplier?

[phpnode]

Jaggi, on 28 March 2012 - 04:06 AM, said:

could we drop the on bit in the widget array to make it simplier?

That won't work if you have properties with the same name as the event, i think qiang's implementation is absolutely fine. One thing though, the second parameter to trigger() should be optional, it should just raise a new default event with the object as the sender if it isn't specified

[Ben]

qiang, on 27 March 2012 - 10:47 PM, said:

// attach an anonymous function to the 'click' event
$button->on('click', function($event) { ... });
// trigger the 'click' event
$button->trigger('click', new Event($this));
// detaches $callback from 'click'
$button->off('click', $callback);
// returns event handlers of 'click' as a vector object so that we can manipulate it
$handlers = $button->getEventHandlers('click');

Just curious: is "trigger" really public? Or was this just for demonstration purpose? I implemented it as protected, because I can't see a reason why events should be triggered from outside.

Can you please include the event name in the "Event" object when it gets triggered? Would be helpful in cases where one event handler is attached to several events.

Third, I think the second parameter of trigger can be made optional:

class Button extends Component
{
  public function foo()
  {
    $this->trigger('fooEvent');
  }

  public function bar()
  {
    $this->trigger('barEvent', new DerivedEvent);
  }

  public function baz()
  {
    $this->trigger('bazEvent', array(
      'eventParamKey' => 'eventParamValue',
    ));
  }
}

class Component
{
  protected function trigger( $eventName, $event=null )
  {
    if ($event === null)
    {
      $event = new Event();
    }
    else if (is_array($event))
    {
      $params = $event;
      $event = new Event();
      $event->params = $params;
    }

    if ($event instanceof Event)
    {
      $event->sender = $this;
      $event->name = $eventName;
    }
    else
    {
      throw new Exception( "Invalid param" );
    }

    // Event prepared, start your event dispatching logic.
  }
}

Maybe not even hard code the "Event" class, but provide a way to configure the default event class that will be created (must derive from Event).