Hi,

I thought about using className as a lightweight alternative to fullfeatured css-selectors.
Let alone the fact that css here can be a great overkill, using selectors you will meet two huge problems:
1. times calling code similar to Element#match() which is slow ( is the number of your rules and you have 6 of them from the very beginning: 'FORM', 'INPUT', etc. This number will grow with the number of your widgets declared);
2. This is hard to deal with rule detalization:
'#container p.my-p a.my-a' '#container p a' '#container p.my-p a' You have to select the most peculiar one that still matches your element.

But classes have no privileges among them (so you can get first matched) and searching through them is reasonably quick (usually, you have 2-3 of them for an element, so you have to do 3-4 queries to Element.Wrappers and this number will NOT grow with the number of your widgets).

So, I don't think this will slow down the $() function dramatically, but I don't mind this implemented as a plugin (ok, in this case I'll try to write it).

fix:
1. N times calling ... (N is the number ...);
(I just wrapped N with angle brackets)

Yes, I get the idea why you use className and that's cool. Just I meant that if you allow one thing, then people will probably want the rest of them.

But you have already allowed one thing!
Registering custom wrappers for tags is available, and people do want the rest. At least some of them :)

But currently it is hard to implement this functionality even as a plugin (I dislike the idea of patching or replacing 'Wrapper' function - this could lead to some difficulties during updates).

some clever thinking over there!

I would bend couple of things here and there but generally, generally I like it.

Could you push your things on github? I'll merge them into the plugins on the weekend.
And for god sake specify you real name, the motherland should know its heros! 8)

Hi,

I cleaned up the code a bit, wrote some documentation and fixed this plugin so that it worked with IE8.
But I'm not able to make it work with old browsers because you didn't provide any way to call "native" querySelectorAll-method (only "find", which in turn calls the $ function again and will probably end up infinitely recursing).

So, to finish this work I need something like querySelectorAll-method returning /bare/ dom elements available for old browsers.

Should I post a ticket for this? Or may be it's better to just remove support for full-featured css-ruled wrappers from this plugin?

BTW: Why to do that parent searching related stuff in the "match" method? (I just want to realize if I can skip this in my "_match" function and use 'document' instead).

Looked into this one once again today, seems like you're right, I'll need to adjust the match method so it worked properly with raw dom elements. Gonna fix it in the 2.1.2 release.

Hi!
Shame on me, I missed the new version of RightJS came out!

Looked into this build today. Looks cool, I see, you've made a Right-thing from my draft :)

There is a little bug in the 'add' method (it seems like broken during refactoring).
Here I put the corrected version: http://pastebin.com/1MNtufCY

Also, I almost didn't test this build, will do later.

No worries, let me know if you'll end up with something working.

btw: I think the tag + key checks should happen before the key ones, coz it's kinda how CSS works, the more specific rules should go first.

I totally agree!

Made this, and also done the following:

• altered RegExps in the "add" method (found a few oddities there);

• moved #id matching before .class ones;

• altered the rules adding/removing procedures so that tag names were always UPPERCASE (except in generic css rules)

e.g.:
Element.Wrappers.add('div.class-name', MyWrapper); // is stored as 'DIV.class-name'
Element.Wrappers.has('div.class-name'); // --> true;
Element.Wrappers.has('DIV.class-name'); // --> true;

• altered the 'has' and 'remove' methods so that they could accept both selectors and wrappers;

e.g.:
Element.Wrappers.add('div.class-name', MyWrapper);
Element.Wrappers.remove('DIV.class-name'); // remove this selector
Element.Wrappers.remove(MyWrapper); // remove all selectors bound to the MyWrapper

• added a NOTE about complex css selectors to the disclamer

But, I still haven't tested it in the IEs...
Will do later :)

Here it is:
http://pastebin.com/BYc0sXLz

Well, after breaf testing this seems to work under IE 6,7,8 and Opera 11!
Don't have any possibility to test under IE9 though.

Nice work! Could you also hook me up with a simple test page? So we could check the things later on

Ok, the simpliest one is included into the archive above.
I'll make a more detailed one in a few days (don't have time today and tomorrow).

BTW: I wonder if there is any way to remove elements from cache
e.g.
MyWrapper = new Class(Element, { getData: function() { return this.get('data-widata'); } });
RightJS.Element.Wrappers.add("div.my-widget", MyWrapper);
alert($('my-widget-1').getData()); // at this point, $('my-widget-1') is cached
RightJS.Element.Wrappers.remove(MyWrapper);
alert($('my-widget-1').getData()); // still works

Removing wrappers will hardly be a frequent operation, but I think, user should be able to decide if he wants to keep all cached Widgets available or not.

okay, thanks, I'll check the things a bit later.

regarding the cache. it get cleaned up automatically when you instance a new wrapper with the same dom-element, kinda like that

var el = document.createElement('div');
el.id = 'boo-hoo';

var wrap1 = new Element(el);
$('boo-hoo') // -> wrap1

var wrap2 = new Element(el);
$('boo-hoo') // -> wrap2

If you feel particularly evil and want to clean it up manually you can do that via the RightJS.Wrapper.Cache list

var el = document.createElement('div');
var wrap = new Element(el);

var uid = $uid(el);
Wrapper.Cache[uid] = undefined;

But be cautious, there are a bit of trickery down there, like for example documents and windows use negative UIDs, Events don't get cached at all and so on. Better use the first approach, it will take care of things automatically.

Hi!
Sorry for being slow, I was busy recently...

Well, removing generic css selectors is ok, but I would keep the other removed features:
* the possibility to call "has" and "remove" with the Wrapper class as an argument; * css-preparation (pre-uppercasing of the tagName) when adding/removing rules. Don't see any reason to throw them away.

Also, just noticed:
You use the following example in the USAGE block: 'div#boo.hoo'. but this kind of selector is not supported by the current version of plugin. I think, USAGE should contain a list of the actually available selectors.

remove actually works with a class, as for the #has one, yes, why not. comments are also fixable :)

Oops, sorry, didn't see it :)
But, well, pre-uppercasing tag names when registering wrapper is not there anyway...
Well, let it be :)