https://bugzilla.wikimedia.org/show_bug.cgi?id=23580
--- Comment #11 from Michael Dale <[email protected]> 2011-09-17 19:35:34 UTC --- That was an example of what people should not do. Presumably people would know better than to use "length" as an object property, bind trigger won't be the only thing that acts funny. I make pretty heavy use of bind trigger model. It certainly has its trade offs but so does a monolithic global hook system. Some points for bind / trigger: Its kind of standard for building reusable hooks into components, its used a lot in jQuery ui for extending ui stuff for example: http://jqueryui.com/demos/accordion/#event-create You mention "different parts of the pages build up can tab into different events and hooks" thats not exclusive to the mediaWiki object, complex components need extendability as well. The bind trigger model integrates nicely when your creating virtual interfaces for components that inter-mix with emerging apis for dom elements. For example you create a virtual iframe to handle uploading you can use a fallback to flash on older browser that triggers the same events, as the modern html5 versions. As the native event becomes available you seamlessly pass the event along the same code path. The bind trigger model also is good about encapsulating bindings in the object representation. So when you copy or duplicate your element / object representation it keeps all its bindings. jQuery based Bind trigger of course plays nice with jQuery so you can bind / trigger on selectors. You can namescape your extension bindings so that its easy to unsubscribe a given extending component. For example you have "player" element. A few modules adding bindings to 'onplay', 'onpause', and 'onend'. Each module namespaces its event binding, i.e: onplay.fooModule so when a controller or sequencer decides it needs to unbind a given module it just runs $(player).unbind(.fooModule) then all fooModule bindings will be removed, with the flexibility to manage this in the controller or in the extending module. You certainly ~could~ build a hook system that had a lot of these qualities but it would not be as simple as .run and .add Maybe the point is simply the master mw object use hook while anything that touches a selector uses bind / trigger. I would be cautions that we don't end up with other components adding events to the core hook system when it would be a better path for the events to be locally bind / triggered. If the core promotes this bind trigger model it may help people think about doing things that way for their module rather then each module setting up a local hook system or mapping and calling all points of extendability with a globally named hook. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
