Events partial wildcard matching #3250

Closed
Ragazzo opened this Issue Apr 25, 2014 · 9 comments

Comments

Projects
None yet
3 participants
@Ragazzo
Contributor

Ragazzo commented Apr 25, 2014

It will be great if events will be also partially matched, so user can subscribe to some events like:

$component->on('user.*')`

in the above user subscribed to all events from user.* like user.signup, user.resetPassword, user.login or other.

Similar functionality presents in other framework and is very useful. However maybe we need to create some helper for partial matching, since it can be widely used: message translations, events, loading fixtures by partial match, and other.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 25, 2014

Member

This doesn't apply to Yii because Yii doesn't use global events (although you can emulate that by registering events with the application instance). Also partial matching will degrade performance, especially when events are triggered on the critical path.

Member

qiangxue commented Apr 25, 2014

This doesn't apply to Yii because Yii doesn't use global events (although you can emulate that by registering events with the application instance). Also partial matching will degrade performance, especially when events are triggered on the critical path.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 25, 2014

Member

What is the usecase of subscribing to arbitrary events? How does your code know how to handle it if it is not know before which event will come?

Member

cebe commented Apr 25, 2014

What is the usecase of subscribing to arbitrary events? How does your code know how to handle it if it is not know before which event will come?

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Apr 25, 2014

Contributor

@cebe use case is to manage entity when some event with it occurs, in the example above we may need to log / filter some additional information without particular khowing what event occured, the thing that matters is that user was changed.

@qiangxue currently i dont see any critical path in Yii that can have some trouble with it.

With such feature we also dont bind to classes and application structure, because Event::on only works when you know classes. I would like to have something like in L4 events. Can we maybe also have queue and flushing events?

Contributor

Ragazzo commented Apr 25, 2014

@cebe use case is to manage entity when some event with it occurs, in the example above we may need to log / filter some additional information without particular khowing what event occured, the thing that matters is that user was changed.

@qiangxue currently i dont see any critical path in Yii that can have some trouble with it.

With such feature we also dont bind to classes and application structure, because Event::on only works when you know classes. I would like to have something like in L4 events. Can we maybe also have queue and flushing events?

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 25, 2014

Member

Along the critical path, we are triggering many events. And whenever an event is triggered, the wildcard matching logic would be involved and every such handler needs to be examined.

There is no fundamental difference between a class name and a name like user. You need to know some predefined name anyway when you want to attach an event handler. With Event::on(), you can also use a base class name.

Member

qiangxue commented Apr 25, 2014

Along the critical path, we are triggering many events. And whenever an event is triggered, the wildcard matching logic would be involved and every such handler needs to be examined.

There is no fundamental difference between a class name and a name like user. You need to know some predefined name anyway when you want to attach an event handler. With Event::on(), you can also use a base class name.

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Apr 25, 2014

Contributor

@qiangxue but if not using application as event manager, but using Event we cant attach event without knowing particular class, so some syntax like Event::on('user.signup', $callback) would be useful. About critical path of the application, partial matching only will be executed for specific handlers, i dont think that there will be a lot of handlers that need to use partial match.
However this feature is useful, so i dont think that there will be a lot of time that need for match and it will not slow down application.
Because in situation Event::on('user.*',$callback) or Yii::$app->on('user.*', $callback) we register only one (in this example) callback that need to match partially, can you explain how this will slow down application? I am not very good with internals.

Contributor

Ragazzo commented Apr 25, 2014

@qiangxue but if not using application as event manager, but using Event we cant attach event without knowing particular class, so some syntax like Event::on('user.signup', $callback) would be useful. About critical path of the application, partial matching only will be executed for specific handlers, i dont think that there will be a lot of handlers that need to use partial match.
However this feature is useful, so i dont think that there will be a lot of time that need for match and it will not slow down application.
Because in situation Event::on('user.*',$callback) or Yii::$app->on('user.*', $callback) we register only one (in this example) callback that need to match partially, can you explain how this will slow down application? I am not very good with internals.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 25, 2014

Member

When you write names like user.*, you already assume the knowledge of user. This is no different from using a class name.

Member

qiangxue commented Apr 25, 2014

When you write names like user.*, you already assume the knowledge of user. This is no different from using a class name.

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Apr 25, 2014

Contributor

it is different, because user.* can be send not only from user class, even more if we skip here entity we cant be sure that events of some one scope will be always triggered from one class.

Contributor

Ragazzo commented Apr 25, 2014

it is different, because user.* can be send not only from user class, even more if we skip here entity we cant be sure that events of some one scope will be always triggered from one class.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 25, 2014

Member

Regarding the performance issue, this is a global event, meaning that whenever you trigger an event, these global event handlers need to be checked to see if they match the event currently being triggered. So this feature, while may be useful, doesn't scale well and should not be promoted.

Using the current class-level events, you can trigger an event like Event::trigger($className, $eventName). So I really don't see the fundamental difference, except that class-level events are more explicit, requiring class names rather than arbitrary names.

Member

qiangxue commented Apr 25, 2014

Regarding the performance issue, this is a global event, meaning that whenever you trigger an event, these global event handlers need to be checked to see if they match the event currently being triggered. So this feature, while may be useful, doesn't scale well and should not be promoted.

Using the current class-level events, you can trigger an event like Event::trigger($className, $eventName). So I really don't see the fundamental difference, except that class-level events are more explicit, requiring class names rather than arbitrary names.

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Apr 25, 2014

Contributor

ok, will skip wildcard matching )

Contributor

Ragazzo commented Apr 25, 2014

ok, will skip wildcard matching )

@Ragazzo Ragazzo closed this Apr 25, 2014

samdark added a commit that referenced this issue Dec 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment