Friday, May 18th, 2007
Automating JS Behavior Registration
Gabriel Handford has created a behavior.js script that allows you to unobtrusively automate Event.observe'tion.
Magic is in naming conventions, so that:
HTML:
-
-
<a class="bvr-observe-click-xhrTheFunction" href="/the/href">The link</a>
-
takes care of:
JAVASCRIPT:
-
-
Event.observe(theLinkElement, "click", function(event) { xhrTheFunction(event) });
-





3.1 rating from 33 votes







It’s amusing that standards freaks actually believe [a class="bvr-observe-click-xhrTheFunction"] is somehow better than [a onclick="xhrTheFunction"].
Yes, exactly, is it April 1st?
it’s sounds like reinventing the wheel ..
That isn’t unobtrusive.
just think about perfomance, when that automation script needs to parse all your DOM to find all event handlers
And how about stopping the observer? May be difficult, since prototype only unregisters observers when passing the same function reference.
No thanks, I’ll take care of events myself.
This reminds me of Dustin Diaz’ Totally Compliant Markup joke, only this isn’t intended to be a joke..
Funny pattern, maybe he should think a bit more about it. Behaviours should not be inline, since its the idea behind behaviours is to split view and controller. Also selectors that only work with classname w/o tag are slower than both tag and classname combined.
Haha, this is ridiculous.
Next step :
HTML :
Hello
JS :
eval(document.getElementById(’foo’).className);
How did I miss that post by Dustin, that’s fantastic!
I’ve also got my 2cents to throw in about the whole behavior.js nonsense but it is a bit too long for a comment (and my trackbacks don’t seem to be working) so you can view it here:
How not to attach events
Is this really worth a headline on Ajaxian?
[Yes] [No]
I click on yes, hoping that the click handler is listening to me.
Hmm, not something I would use in an application, I try to stay away from using the class attribute for anything except styles.
The power of behaviors is that it attaches javascript to DOM elements… not just onClick behaviors, but anything. Behaviors can do anything at init time (move stuff around in the DOM, anything), attach to multiple keyboard/mouse events, etc. And behaviors can be object oriented so you can have a mouseover event and a mouseout event tied to the same object that that also does loading stuff at init time.
This was just a proof of concept (and not even entirely functional). The idea was to parse the DOM all in one shot, so if you have a ton of behaviors, you don’t have to deal with alot of selector rules. You could add other naming conventions to automate common tasks, do binding, etc.
It is verbose, inefficient, not original or entirely unobstrusive, and probably not worthy of a spotlight on ajaxian :O
Sorry for all the pooh pooh Gabe. I thought it looked interesting and so submitted it without your consent. ..Err next time maybe I’ll just let you do it. :/
(but hey at least you got some more hits - even if they were angry pooh pooh hits ;) )
Hey,
Do have a look over at Returnable.org .
its a project that attempts to allow intuitive event based content delivery to spawn javascript code using a simple html api.
check out the alpha released some time back at returnable.org.
Keep Clicking,
Bhasker V Kode,
Lead Archtiect - Returnable