[wp-hackers] Question about the architecture of the admin widgets.php

[John BouAntoun]

So are you suggesting, that rather than the selector gymnastics I do to
catch the events that are problematic i should just overload the target
functions that are called on the event firing.

Sounds like a workable solution, but still not really a clean approach,
since I, as a plugin developer am still "replacing" core functionality,
instead of placing custom code before/after the core functionality. Am
mainly thinking in terms of defending against future core changes breaking
the plugin.

If I "replace" a function whose signature is changed in a future core
upgrade I get a broken plugin. If i use a core event binding/queuing
mechanism, then the chances are that the signature changing core update will
be made evident to me earlier and perhaps even backwards compatible.

Thanks for the tip. Will have a crack at reworking my plugin to replace the
object methods instead of the actualy jQuery events.

JBA

On Tue, Jan 5, 2010 at 3:11 PM, Andrew Ozz <admin at laptoptips.ca> wrote:

> Don't forget that JS is not like PHP, it's very easy to redeclare and
> overload. The "standard" hack for this is to do something like:
>
> wpWidgets.save1 = wpWidgets.save;
> wpWidgets.save = function(){
>  check the widget;
>  do what you need;
>  this.save1()...
> }
>
> We could design some kind of JS hooks for core, probably based on custom
> events in jQuery (since they are so easy). Something like:
>
> jQuery('body').trigger('eventName', [arg1, arg2]);
>
> and plugins can do:
>
> jQuery('body').bind('eventName', function(event, arg1, arg2){ ... });
>
> But since everything can be redeclared easily, not sure if they are needed
> that much.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>