Changes between Initial Version and Version 1 of Ticket #21170, comment 35
- Timestamp:
- 07/16/2012 10:37:53 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #21170, comment 35
initial v1 3 3 It works like this: 4 4 5 ''' 5 {{{ 6 6 // setup in core somewhere, or elsewhere 7 7 var actions = { … … 24 24 // later when it comes time to cleanup: 25 25 actions.wpAction.myNamespace.remove(); 26 ''' 26 }}} 27 27 28 28 I didn't add a way to dispatch a Signal only to a namespaced sub-set of listeners, because it didn't seem to make sense to expose that kind of functionality. If a listener was added to a Signal, it seems inappropriate to only send the signal to certain listeners, it adds a second level of subscriber sets, and that can be abused to basically duplicate the dispatcher functionality, where there should probably be a second named action - it may be better to encourage the creation of another distinct hook. … … 30 30 I think event namespaces are mostly useful as a tool for plugin developers to use to be able to clean themselves up, without having to retain a reference to all the listeners they may add all over. 31 31 32 jQuery does support namespaced dispatching, and if there was a strong desire for namespaced dispatching, it could be added easily to SignalsLite.js. I'm not sure how often you'd have plugin or extension developers triggering or dispatching actions and filters (like they frequently do in jQuery), so it may not really be an issue, unless it's wanted for core use. 32 jQuery does support namespaced dispatching, and if there was a strong desire for namespaced dispatching, it could be added easily to SignalsLite.js. I'm not sure how often you'd have plugin or extension developers triggering or dispatching actions and filters (like they frequently do in jQuery), so it may not really be an issue, unless it's wanted for core use 33 34 Edit: I used the wrong markup format. heh