Thanks John, It's sooo close. But it doesn't read the selectors of the query (because of the return jQuery.fn.init.call(this)) so this in the plugins always refers to the document. If you try to do an apply(this, arguments) or even manually pass in the arguments to .call() it doesn't work (it won't even attach anything to subClass.fn). Any insight you can give is GREATLY appreciated :)

Nate Cavanaugh Director of User Interface Engineering Liferay, Inc. Enterprise. Open Source. For life.

On Nov 12, 2008, at 11:51 AM, John Resig wrote:

Fixed it: http://dev.jquery.com/~john/plugins/subclass/

The issue was that in: subClass.fn.init.prototype = subClass.prototype;

subClass.fn.init was just a reference to jQuery.fn.init - thus when you modified its prototype property you were modifying the original jQuery init prototype property - breaking future uses. Thus you just have to do a quick little wrapper function around the original init, like so:

var subClass = function(selector, context){ return new subClass.fn.init(selector, context); };

subClass.fn = subClass.prototype = jQuery(); subClass.fn.init = function(){ return jQuery.fn.init.call(this); }; subClass.fn.init.prototype = subClass.prototype;

Which could be made into a reusable function:

function subjQuery(){ var subClass = function(selector, context){ return new subClass.fn.init(selector, context); };

subClass.fn = subClass.prototype = jQuery(); subClass.fn.init = function(){ return jQuery.fn.init.call(this); }; subClass.fn.init.prototype = subClass.prototype;

return subClass; }

var myNewjQuery = subjQuery();

--John

On Wed, Nov 12, 2008 at 2:29 PM, Nate Cavanaugh <na...@shift22.com> wrote:

Thanks John :)

I think this has solidified the issue I was seeing, and it might not be an

issue at all, but it's insanely weird...

var subClass = function(selector, context){

return new subClass.fn.init(selector, context);

};

subClass.fn = subClass.prototype = new jQuery.fn.init();

subClass.fn.init.prototype = subClass.prototype;

jQuery.fn.t2 = function(){

console.log('jQuery plugin', this, arguments);

};

subClass.fn.t2 = function(){

console.log('subClass plugin', this, arguments);

};

subClass('body').t2(1,2); //Should print out 'subClass plugin, [body],

[1,2]'

jQuery('body').t2(3,4); // Should print out 'jQuery plugin, [body], [3,4]',

but prints subClass plugin, [body], [3,4]

console.log(jQuery.fn.t2, jQuery.fn.t2 === subClass.fn.t2); // returns

false, as expected

It is driving me nuts, I can't make heads or tails of whats happening...

Nate Cavanaugh

Director of User Interface Engineering

Liferay, Inc.

Enterprise. Open Source. For life.

On Nov 12, 2008, at 11:17 AM, John Resig wrote:

Tweaked your example to make that work - it now works for both queries

and adding methods:

http://dev.jquery.com/~john/plugins/subclass/

You did:

subClass.fn.init= subClass.prototype;

Which should've been:

subClass.fn.init.prototype = subClass.prototype;

--John

On Wed, Nov 12, 2008 at 2:08 PM, Nate Cavanaugh <na...@shift22.com> wrote:

Heya John,

Thanks for the response, and sorry I wasn't more clear. I've tried so many

different variations of this, that I can't remember which did what.

That one does keep the chain properly in place, but this doesn't work:

subClass('body') // Should error out and say subClass.fn.init is not a

constructor.

Every way I was able to get the above to work, it would only do so by

maintaining the link between subClass.fn and jQuery.fn.

Is there any other way you can think of that would essentially (and in a way

that's performant) extend a new object off the jQuery object?

Thanks again for your guys time :)

Nate Cavanaugh

Director of User Interface Engineering

Liferay, Inc.

Enterprise. Open Source. For life.

On Nov 12, 2008, at 6:37 AM, John Resig wrote:

Try as I might I can't reproduce your problem. I created a test page:

http://dev.jquery.com/~john/plugins/subclass/

I overwrote the removeClass method and they're both different on each

object (subClass vs. jQuery).

Maybe there's another mistake at play?

--John

On Tue, Nov 11, 2008 at 6:37 PM, Nate Cavanaugh <na...@shift22.com> wrote:

Hi all,

As promised, here is the second topic I wanted to ask about:

Are there any plans, or is there any current way to subclass the jQuery

object? I've been doing a lot of digging around and I've seen some talks

about it, and there have been some questions about what the use would be,

but I've found a use case, and me, Paul, and Eduardo have all tried to

figure out a way, but to no avail.

Here is the use case:

I want to create a function that behaves exactly like jQuery, except that it

does some slightly different things, and be able to extend it without

worrying about what the parent jQuery object is doing, or what plugins have

been loaded globally.

The benefits are that it would use the prototype chain, so it would be

memory efficient, and it would be a way to add plugins without them being

clobbered by other plugins.

So, I've tried a bunch of stuff:

var subClass = function(sel, context){

return new subClass.fn.init(sel, context);

}

subClass.fn = subClass.prototype = new jQuery.fn.init;

subClass.fn.init = subClass.prototype;

and I've tried so many different variations of this, but anytime I try to

do:

subClass.fn.test = function(){}

it, without fail, creates jQuery.fn.test.

To show what I am trying to do, I'll give an example:

jQuery.fn.plugin1 = function(){

console.log('I am global, everyone can see me');

return this;

} // globally available plugin

subClass.fn.plugin1 = function(){

console.log('I am local, and I am only run when using the subclass');

return this;

} // my own local plugin

so you could do:

jQuery('body').plugin1(); // prints 'I am global, everyone can see me'

subClass('body').plugin1(); // prints 'I am local, and I am only run when

using the subclass'

However, namespaced plugins is only one advantage. Being able to attach

custom static methods, etc, would be incredibly useful.

Does anyone know of a way to subclass the jQuery object using it's

prototype?

Thanks again for reading all of this. I truly appreciate it,

Nate Cavanaugh

Director of User Interface Engineering

Liferay, Inc.

Enterprise. Open Source. For life.

Nate Cavanaugh

Director of User Interface Engineering

Liferay, Inc.

Enterprise. Open Source. For life.

Nate Cavanaugh

Director of User Interface Engineering

Liferay, Inc.

Enterprise. Open Source. For life.