Thursday, April 5th, 2007
Category: JavaScript
, Library
<
>p
>Ryan Johnson is quite prolific these days. His newest creation is
Event.Behavior, a domain specific language for describing and defining events in your JavaScript applications. It attempts to approximate how one would describe an event in the english language and allows you to extend it with your own verbs.
The library was inspired by Adam McCrea's presentation on Meta programming with JavaScript, and is built on top of Prototype 1.5.
Here are some examples:
JAVASCRIPT:
-
-
with (Event.Behavior) {
-
show('postal_code_field').when('country_select').is('United States').or('Canada');
-
-
set_style(styles).on(paragraphs).when(selects).change();
-
-
add_class_name('black').to('paragraph').when('color_select').is('black');
-
}
-

- Ajax seen solving JavaScript issues for RIA
For rich Internet application (RIA) development, Ajax is doing for JavaScript what JavaScript couldn't do alone, the author argues. "The browser wars...
- FAQ: Lotus Notes, Domino and JavaScript
Caught in a JavaScript jam? Before posing a question to our SearchDomino.com experts, check out our list of frequently asked questions on JavaScript...
- Junk JavaScript?
Should JavaScript and HTML be replaced with "proper" languages that might give more bang for the buck in rich Internet applications (RIAs)? One reader...
- JavaScript Learning Guide
This SearchDomino.com guide introduces you to JavaScript in a Notes/Domino environment, explains best practices and pitfalls to avoid and provides...
- JavaScript Library in a Notes database
Do you need the same JavaScript code in many Notes forms? This tip will shows you how you can maintain JavaScript code in only one...
Wow very insteresting project … bonus, It will help me to improve my english ;)
Very interesting indeed. I bet Adam didn’t see this one coming. Congrats to Ryan on putting a good idea to work.
um….. can anyone say “big deal” and/or why is pseudocode being heralded as an invention??
i thought pseudocode meant code that shows an idea but doesn’t actually run
Interesting idea, but please don’t sacrifice code quality for dumbed down readability, that’s what comments are for. One of the examples on that page is:
with(Event.Behavior){
add_class_name(‘black’).to(‘paragraph’).when(‘color_select’).is(‘black’);
add_class_name(‘red’).to(‘paragraph’).when(‘color_select’).is(‘red’);
add_class_name(‘green’).to(‘paragraph’).when(‘color_select’).is(‘green’);
add_class_name(‘blue’).to(‘paragraph’).when(‘color_select’).is(‘blue’);
add_class_name(‘bold’).to(‘paragraph’).when(‘weight_select’).is(‘bold’);
add_class_name(‘normal’).to(‘paragraph’).when(‘weight_select’).is(‘normal’);
}
This should be simply:
$(‘color_select’,'weight_select’).invoke(‘observe’,'change’,function(event){
$(‘paragraph’).addClassName(Event.element(event).value);
});
I could be wrong but I’m guessing each Event.Behavior “statement” is a separate event observer, so not only is this example extremely verbose, but it’s also very inefficient and not maintainable. However, some other examples they used were actually pretty cool.
Suggestion: for all constructs that can take a function which returns an array of elements, you could make the code much cleaner by allowing you to pass a string which is assumed to be a CSS selector, in which case it would pass that to $$ itself rather than requiring you to pass it a function that just wraps $$. This would also be more readable since you don’t have ugly inline functions or functions defined elsewhere.
Example:
with(Event.Behavior){
set_style(styles).on(‘#font_picker p’).when(‘#font_picker select’).change();
}