Extending selectors to support custom objects
Now that I ran into the issue again I'm going to revive a bit of an old
thread of mine.
Extensibility: Extending init selectors to support application objects
http://groups.google.com/group/jquery-dev/browse_thread/thread/c0743849212a360a/f797c0d2f54dd9cc
The gist of the thread is talking about a feature letting you extend
jQuery to handle custom objects properly.
ie: If you have a Widget system in your app, you could extend jQuery so
that $(widgetObject) and $(this).append(widgetObject); are smart enough
to know how to handle the widget object (ie: Grabbing the proper dom
note for the widget).
Originally the discussion stopped because someone noted that you could
override jQuery.fn.init with a proxy method to achieve this ability.
I was doing some work today on our the version of the app the company I
work for is building, and after spending some time tracking down a bug I
ended up finding that it was caused by the fact that overriding .init
actually doesn't handle this feature properly.
.append(obj); goes directly into domManip and never makes it's way to
init, so as a result this feature does not work. At the moment I'm
working around this by hacking jQuery.clean with an extra, ugly proxy
method. But either something has changed in jQuery since that time then,
or this never worked from the start.
This considered, I think this feature in one of three forms would be good:
- Things which go directly to domManip make their way to init at some
point so overriding it will work.
- Making jQuery understand a callback name which it can look for in
custom objects. ie: Add jQuerySelectCallback or whatever to your
Widget's prototype and jQuery will use that to select the node.
- The proposed feature of having a callback list jQuery understands
which is used in init, and wherever else necessary to allow for this
feature to work.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--