Yup, that is one of the possibilities I considered.
Though I was also considering the callbacks for selector rewriting.
There was an old case on the list about people passing objects to init:
$({id: 'foo'});
That can't properly be handled by the prototype trick. ^_^ It also has a
nice use case going for it since it's expressive and special character safe.
$({id: someUserSuppliedIdThatCouldContainSpecialCharactersLikeAColon});
It's perfectly possible to implement both features. A callback list
doesn't hit performance if there aren't any callbacks. Then you can use
what's suitable and get both performance and flexibility advantages.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Dave Methvin wrote:
I'm working on a patch to jQuery to make it so that initialization can
support application specific objects through extensibility.
How about if your Widget had a method like:
Widget.prototype.jQueryGet = function(){
return #widget-+this.id;
};
Then jQuery's init() could do something like this at the very top:
if ( selector jQuery.isFunction(selector.jQueryGet) )
selector = selector.jQueryGet(context);
Then you can expose whatever you want to jQuery (string selector, DOM
nodes, ready function, etc.) It's a single check in the constructor
rather than a chain of callbacks that have to be invoked on every
jQuery construction, so it certainly has performance going for it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
