danwebb.net - Low Protag:danwebb.net,2011:mephisto/lowproMephisto Noh-Varr2009-07-02T11:32:57Zdantag:danwebb.net,2009-07-02:33732009-07-02T11:22:00Z2009-07-02T11:32:57ZLow Pro for Prototype and Firefox 3.5
<p>Just a quick note for those googling for a solution to this. Older versions of Low Pro for Protoype will be experiencing problems with behaviors in Firefox 3.5. This issue has been fixed so pick up the latest version <a href="http://github.com/danwrong/low-pro/raw/2f47a651ab1143b2e067de7d2381f615c389a14e/dist/lowpro.js">from GitHub</a></p>
<p>An interesting upshot of this is that I found out something pretty nice which is kind of obvious but had never occurred to me before. If you create a function in a closure then that function can refer to itself because it has access to that closure’s variables. I normally use arguments.callee to get a reference to a function from within its body but there’s never really any need to do that:</p>
<pre><code class="javascript">(function() {
var aFunction = function() {
aFunction.thing = 47;
};
aFunction();
alert(aFunction.thing); //=> 47;
})();</code></pre>
dantag:danwebb.net,2008-06-23:33422008-06-23T22:56:00Z2008-06-24T00:24:12ZIt's Been A Long Time...
<p>But I’ve not just been sitting on my arse playing <span class="caps">GTA IV</span>, oh no. Well, not all the time anyway. The reason I’ve not posted anything (or been particularly active on the web in general) is that I’ve been damn busy. Most importantly, Catherine kindly gave birth to our first son, <a href="http://flickr.com/photos/danwebb/2361976989/">Max</a>, back in March which has been quite a change and sapped a lot of my hacking time. I have to say though, despite the horror stories that many veteran parents like to feed you, our experience has only been good. In fact, not good, great. I recommend this reproducing lark.</p>
<p>Secondly, I’ve been hacking away nearly full time on one of my favourite projects to date, <a href="http://peoplesmusicstore.com">Peoples Music Store</a> with <span class="caps">LRUG</span> stalwart and renowned anarchist, <a href="http://abscond.org">James ‘Bringing London To Its Very Knees’ Darling</a> which is maturing nicely under private beta as we speak. Peoples Music Store is a great idea from some of the guys behind <a href="http://bleep.com">bleep.com</a> whereby users can construct and customise their very own download store from the music they love then get free music themselves if people buy from their store. It’s a great way to both promote and show off you’re own music taste or in depth genre knowledge and find new music from stores you trust while getting some free digital swag along the way. I’m probably not explaining it well so just drop me a line if you want and invite and the site will explain itself. Public launch is coming in a month or so.</p>
<p>Building Peoples Music Store has been a great learning experience. We run the site on a cloud computing platform and from content ingestion to audio preview delivery to application servers to download packaging and delivery everything has been designed to scale horizontally – and I’m pretty proud of it. Thin, Rack, Sphinx, God, Starling and a whole load more cool open source gear is all running in there. I really need to get to blogging some of what I’ve discovered about working with <a href="http://rack.rubyforge.org/">Rack</a>. It simply is the dog’s bollocks.</p>
<p>So, enough of the excuses. What’s on the horizon?</p>
<h3>Speaking and Conferences</h3>
<p>I’ve taken some time of speaking and conferencing in general so as to spend lots of time with Catherine and Max but come September I’m restarting the conference trail. Firstly, I’m doing a presentation and a tutorial (with <a href="http://jlaine.net">Jarkko Laine</a>) at RailsConf Europe all about JavaScript related Rails stuff and I’m likely to have a slot at <a href="http://vivabit.com/atmediaajax">@media Ajax</a> as well. Also, I’ll be heading to <a href="http://2008.dconstruct.org">dConstruct</a> as is the tradition.</p>
<h3>Hacking and Open Source Business</h3>
<p>Although I’ve not commited to Low Pro or Low Pro JQ for a good while now they are both very much alive. I’ve simply not come across anything that I’ve felt the need to add for a while. If you have any suggestions or patches do let me know. I’ve actually got time to commit them at the moment. Another little project that I’m hoping to get off the ground is called <strong>Evil</strong> which is going to contain lots of Merb/Rack goodness. The first by-product of which is the <a href="http://github.com/danwrong/merb_openid">merb_openid</a> gem for consuming OpenID in Merb apps (it’s still not quite production ready though so don’t go using it just yet). I’ll let you know what Evil actually does when (or if) I actually get something working.</p>
<p>So, that’s all for now. Just a bit of a status report. I promise I’ll get some useful content written that you actually care about very soon.</p>
dantag:danwebb.net,2008-02-08:30472008-02-08T13:10:00Z2008-03-07T21:06:20ZEvent Delegation Made Easy
<p>I’m having a lot of fun poking around jQuery at the moment and came up with a cool little thing that’s going into Low Pro for jQuery but is a nice stand-alone little snippet for implementing event delegation. Since the <a href="http://icant.co.uk/sandbox/eventdelegation/">Christian and the guys at <span class="caps">YUI</span> started talking about it</a> event delegation has gone from being something that I’d use occasionally to the way I do nearly all my event handling. If you aren’t familiar with the technique go and click that previous link and read Christian’s article now – it’s important.</p>
<p>In most instances I end up writing a lot of event handlers that look like this:</p>
<pre><code class="javascript">$('#thing').click(function(e) {
var target = $(e.target);
if (target.hasClass('quit') return doQuitStuff();
if (target.hasClass('edit') return doEditStuff();
// and so on...
});</code></pre>
<p>Obviously, writing a lot of the same kind of code is a warning sign that something needs refactoring but I’ve never come up with a nice way to abstract this. But with a little bit of functional magic I’ve just found with something I really like. Here’s what I came up with:</p>
<pre><code class="javascript">jQuery.delegate = function(rules) {
return function(e) {
var target = $(e.target);
for (var selector in rules)
if (target.is(selector)) return rules[selector].apply(this, $.makeArray(arguments));
}
}</code></pre>
<p>Using it is simple:</p>
<pre><code class="javascript">$('#thing').click($.delegate({
'.quit': function() { /* do quit stuff */ },
'.edit': function() { /* do edit stuff */ }
}));</code></pre>
<p>The function simple runs through the rules checking if the element that fired the event belongs to that selector then calls the corresponding handler passing the original event object through. The great thing about it is that you can use it in Low Pro behavior classes:</p>
<pre><code class="javascript">DateSelector = $.klass({
onclick: $.delegate({
'.close': function() { this.close() },
'.day': function(e) { this.selectDate(e.target) }
}),
selectDate: function(dayElement) {
// code ...
},
close: function() {
// code ...
}
});</code></pre>
<p>I’m not sure of the performance implications of using is() so heavily but some form of caching could be added if it was a problem. Still, it’s a really nice little bit of syntactic sugar that’s going into Low Pro for jQuery and I’ll be using it a lot.</p>
<p><strong><span class="caps">UPDATE</span></strong>: I should have added that there’s a version of this in Low Pro for Prototype. In case you want to use it on its own:</p>
<pre><code class="javascript">Event.delegate = function(rules) {
return function(e) {
var element = $(e.element());
for (var selector in rules)
if (element.match(selector)) return rules[selector].apply(this, $A(arguments));
}
}</code></pre>
<p>Meanwhile, you might want to take a look at <a href="http://peter.michaux.ca/article/3752">the patch</a> by <a href="http://peter.michaux.ca/">Peter Michaux</a>.</p>
dantag:danwebb.net,2008-02-03:30022008-02-03T16:00:00Z2008-02-04T00:28:00ZHow To Use Low Pro For jQuery<p>It seems that my initial version of <a href="http://github.com/danwrong/low-pro-for-jquery/tree/master/src/lowpro.jquery.js?raw=true">Low Pro for jQuery</a> has gotten enough interest to continue
with it but, as always, my previous post was extremely lacking in actual detail about how to use
the damn thing. So without further ado here we go. It’s pretty simple really and, as its a port
of a subset of Low Pro for Prototype, anything that goes for that also goes for jLow.</p>
<p>Heh, let’s not call it that again. Bad.</p>
<p>Anyway, on with the show…</p>
<p>It seems that my initial version of <a href="http://github.com/danwrong/low-pro-for-jquery/tree/master/src/lowpro.jquery.js?raw=true">Low Pro for jQuery</a> has gotten enough interest to continue
with it but, as always, my previous post was extremely lacking in actual detail about how to use
the damn thing. So without further ado here we go. It’s pretty simple really and, as its a port
of a subset of Low Pro for Prototype, anything that goes for that also goes for jLow.</p>
<p>Heh, let’s not call it that again. Bad.</p>
<p>Anyway, on with the show…</p>
<h3>Class-based OO</h3>
<p>In order for Low Pro behavior classes to work with jQuery we need a class implementation. The
one I’ve based this on is the version from Prototype originally based on Alex Arnell’s work. This
is detailed in <a href="http://prototypejs.org/learn/class-inheritance">this article on the prototype site</a>. The
only difference is that instead of using Class.create you use $.klass:</p>
<pre><code class="javascript">Draggable = $.klass({
initialize: function(options) { },
onmousedown: function() {}
});
GhostedDraggable = $.klass(Draggable, {
onmousedown: function($super) {
// do extra stuff here then call original method...
$super();
}
});</code></pre>
<h3>Attaching the behavior class to elements</h3>
<p>To attach the behavior class to some
elements you can use the attach method:</p>
<pre><code class="javascript">$('div.product').attach(GhostedDraggable, { anOption: thing });</code></pre>
<p><code>attach</code> creates a new instance of the given behavior class for each element in the collection and
attaches them to these elements. Any subsequent arguments are passed to the class’s <code>initialize</code> function.
A few magic things happen here. First, <code>this.element</code> in the
behavior instance is set to a dollared version of the element it’s attached to. Secondly, every
method beginning with on (eg. onclick, onsubmit etc) gets bound as an event handler on the attached
element. However, in the event handler functions themselves, <code>this</code> points to the behavior instance
rather than the element so you can call it’s other methods. You can obviously get to the element
by using <code>this.element</code> if you need to though.</p>
<h3> And for the bonus round…</h3>
<p>So, that’s about all there is to it. One added bonus is that if you are using <a href="http://brandonaaron.net/docs/livequery/">livequery</a> then Low
Pro will automatically use it to attach any new behaviors after the <span class="caps">DOM</span> is changed without you needing to worry about it.</p>
<p>Here’s a super simple example behavior that simply adds and removes a <span class="caps">CSS</span> class name when it is
hovered over. It’s about as bare bones as you can get while showing off most of the features:</p>
<pre><code class="javascript">Hover = $.klass({
initialize: function(hoverClass) {
this.hoverClass = hoverClass;
},
onmouseover: function() {
this.element.addClass(this.hoverClass);
},
onmouseout: function() {
this.element.removeClass(this.hoverClass);
}
});
jQuery(function($) {
$('span.name').attach(Hover, 'myClassName');
});</code></pre>
<p>For more information about how you might use behavior classes take a look at <a href="/2007/7/18/low-pro-behaviours-101-part-2">this article.</a> ANother good point of reference is the built-in Remote.Link and Remote.Form
behaviors that are built in to Low Pro. Take a look at the <a href="http://github.com/danwrong/low-pro-for-jquery/tree/master/src/lowpro.jquery.js?raw=true">source</a>
Also a Low Pro site is on its way shortly. As I use it more myself I’ll post more real examples but you can post any questions to the <a href="http://groups.google.co.uk/group/low-pro">Low Pro list</a>.</p>
dantag:danwebb.net,2008-01-31:29712008-01-31T00:56:00Z2008-01-31T14:43:25ZLow Pro For jQuery?<p>A few days ago <a href="http://groups.google.co.uk/group/low-pro/browse_thread/thread/29b96e32fb68f45e">a discussion started about porting Low Pro over to jQuery</a>. It’s been on my mind
for a while (especially since <a href="http://meme-rocket.com/2007/09/07/agnostic-unobtrusive-javascript/">Bill blogged about agnostic <span class="caps">UJS</span></a>) but I’d hesitated in doing this for a few
reasons. Firstly, of course, jQuery is the mortal enemy of Prototype and only one library shall
remain come The Quickening. Aside from this completely rational reason, I wondered whether jQuery
really needed anything like Low Pro at all. After all, jQuery has always been designed with
‘unobtrusiveness’ in mind and was written with most of what Low Pro originally intended to fix
in Prototype implemented from the start. There was no need for something like Event.addBehavior
because essentially that’s what jQuery is:</p>
<pre><code class="javascript">Event.addBehavior({
'a.external:click': function() { //...code...// },
'div.product:mouseover': function() { //...code...// }
});</code></pre>
<p>Can be achieved in jQuery like this:</p>
<pre><code class="javascript">jQuery(function($) {
$('a.external').click(function() { //...code...// });
$('div.product').mouseover(function() { //...code...// });
});</code></pre>
<p>And rather than ever going near inline event handlers this unobtrusive style was the de-facto
method of working for the jQuery crowd. The angel on your scripting shoulder. However, as you
can probably tell from reading this blog, I’ve never really adopted jQuery as my main library
and this was due to one big reason (and a bundle of small ones but I’ll leave them out)...</p>
<p>A few days ago <a href="http://groups.google.co.uk/group/low-pro/browse_thread/thread/29b96e32fb68f45e">a discussion started about porting Low Pro over to jQuery</a>. It’s been on my mind
for a while (especially since <a href="http://meme-rocket.com/2007/09/07/agnostic-unobtrusive-javascript/">Bill blogged about agnostic <span class="caps">UJS</span></a>) but I’d hesitated in doing this for a few
reasons. Firstly, of course, jQuery is the mortal enemy of Prototype and only one library shall
remain come The Quickening. Aside from this completely rational reason, I wondered whether jQuery
really needed anything like Low Pro at all. After all, jQuery has always been designed with
‘unobtrusiveness’ in mind and was written with most of what Low Pro originally intended to fix
in Prototype implemented from the start. There was no need for something like Event.addBehavior
because essentially that’s what jQuery is:</p>
<pre><code class="javascript">Event.addBehavior({
'a.external:click': function() { //...code...// },
'div.product:mouseover': function() { //...code...// }
});</code></pre>
<p>Can be achieved in jQuery like this:</p>
<pre><code class="javascript">jQuery(function($) {
$('a.external').click(function() { //...code...// });
$('div.product').mouseover(function() { //...code...// });
});</code></pre>
<p>And rather than ever going near inline event handlers this unobtrusive style was the de-facto
method of working for the jQuery crowd. The angel on your scripting shoulder. However, as you
can probably tell from reading this blog, I’ve never really adopted jQuery as my main library
and this was due to one big reason (and a bundle of small ones but I’ll leave them out)...</p>
<p>The one big reason was that, while jQuery was super simple and concise when working on smaller
projects, it offered no help in structuring larger applications. All you get in jQuery, aside from
Ajax methods and a handful of utilities, is the ability to select nodes then doing something
with them. On the other hand Prototype is much rounder in scope. It generally plumps out JavaScript
as a language adding lots of useful methods to built-ins, a host of functional programming tools
and recently a full Class-based OO system with inheritance and the whole shebang which has formed
the back bone of Low Pro’s behavior classes.</p>
<p>Low Pro’s behavior classes have become my favourite solution to the problem of structuring complex
Ajax applications in a simple and maintainable way. Even hugely complex applications can be separated
up into a number of groups of elements with attached behaviors. These behaviors maintain their
own state, respond to events and can also expose there own public methods. They are linked to an
element but the element doesn’t know about them which eliminates the need for expandos on elements and
also most of the reasons for having element references in closures which is good for keeping memory usage
at bay. For instance, a click on
a TabBar instance can call the loadContent method of a ContentPanel. The result is more than a
set of widgets, its a way of splitting up huge complicated interfaces into a collection of small,
loosely joined parts each simple in its own right and totally responsible for its part of the interface.
This approach becomes incredibly useful when you introduce server-side requests and responses into
the mix but that’s a whole other article.</p>
<p>In jQuery land this kind of effect can be achieved via plugins. You’ll find a ton of widgets
in the repository that have this kind of UI:</p>
<pre><code class="javascript">$('#example4').draggable({ helper: 'clone', revert: true });</code></pre>
<p>The plugin architecture is one of jQuery’s many strong points but this kind of approach has a couple
of disadvantages. Firstly, the plugin is created within a closure which means usually if you want to
change the behavior of the plugin you literally need to pop open the source and change it. The second
and related disadvantage is that because of the difficulty in changing plugins they tend to have
a whole raft of options to allow you to configure how it works. The problem with this is that
individual widgets can end up pretty monolithic. Wouldn’t it be be better if you could just take
the basic draggable behavior and just augment it to your liking?</p>
<p>Well, in Low Pro behaviors are classes so we can do this by simply subclassing another behavior
and overriding or adding what we need. For example, we can create GhostedDraggable as a subclass
of Draggable. No need to hack any existing code at all. As well as having the power and convenience
of jQuery’s <span class="caps">DOM</span> manipulation we can have a simple and powerful way to structure larger, more
complex applications. I can have my jQuery cake and eat it.</p>
<p>So, I’ve started experimenting with <a href="http://github.com/danwrong/low-pro-for-jquery/tree/master/src/lowpro.jquery.js?raw=true">Low Pro for jQuery.</a>
Here’s a preview:</p>
<pre><code class="javascript">Hover = $.klass({
initialize: function(hoverClass) {
this.hoverClass = hoverClass;
},
onmouseover: function() {
this.element.addClass(this.hoverClass);
},
onmouseout: function() {
this.element.removeClass(this.hoverClass);
}
});
$('div.products').attach(Hover);</code></pre>
<p>If you want to leave feeedback or abuse <a href="http://groups.google.co.uk/group/low-pro">jump on the Low Pro list.</a>
Do you think it has a place in the jQuery landscape? How do you currently structure complex applications
in jQuery?</p>
<p><strong><span class="caps">UPDATE</span></strong>: Thanks to Chris of <a href="http://errtheblog.com">Err The Blog</a> Low Pro JQ is <a href="http://github.com/danwrong/low-pro-for-jquery/tree/master/">rocking on GitHub</a>. Fork away.</p>
dantag:danwebb.net,2007-12-12:25582007-12-12T00:23:00Z2007-12-13T17:49:59ZLow Pro 0.5: Now Compatible With Prototype 1.6
<p>Today I <a href="http://svn.danwebb.net/external/lowpro/tags/rel_0.5/">tagged Low Pro 0.5</a> for release which now works with Prototype 1.6. There are a number of things about this release that are worth mentioning aside from the compatibility. Firstly, it’s gotten a little smaller as Prototype core now includes most of the functionality Low Pro used to add (DOM Ready support, inserting using <span class="caps">DOM</span> nodes and a lot more). It’s also got a couple of new features so here’s a rundown:</p>
<ol>
<li><strong>Event.onReady delegates to the new dom:loaded event</strong>: Except that as before if functions are added after the <span class="caps">DOM</span> is loaded they fire immediately.</li>
<li><strong>DOMBuilder now delegates to Prototype’s new Element</strong>: Now difference in usage here though, just less code.</li>
<li><strong>Low Pro’s <span class="caps">DOM</span> methods are now gone</strong>: Prototype core does everything you should need now.</li>
<li><strong>Behavior.create() works just like the new Class.create()</strong>: Yes, you can now create behavior classes that inherit from other behaviors (or indeed any other class). <a href="http://prototypejs.org/learn/class-inheritance">See the Prototype’s site for more information.</a></li>
<li><strong>New core behaviors</strong>: The Remote and Observed behaviors are now included in the core so you can now turn normal links and forms into Ajaxy links and forms even more easily.</li>
<li><strong>Event.addBehavior.reassignAfterAjax is now false by default</strong>: Normally, if you are relying on this behavior it’s much more efficient to move to a solution using event delegation. However, if you do want your behaviors reassigned to new content after Ajax calls then go ahead and set it back to true again. Another solution is to manually call Event.addBehavior.reload();</li>
</ol>
<p>So that’s about it. As you can see, it’s getting smaller as Prototype fills the gaps and graduating into more of a pure behavior framework. I’d be interested in adding more core behaviors for other common tasks as well as possibly getting together some kind of behavior library. I know I’m building up a fair few and I’d love to see what everyone else is doing (in fact I’ve already seen some great stuff) so suggestions are more than welcome…as are bug reports and patches. For both of these and general assistance try <a href="http://groups.google.co.uk/group/low-pro">the Google Group</a>.</p>
<p><a href="http://svn.danwebb.net/external/lowpro/tags/rel_0.5/dist/lowpro.js">Grab the new version</a> and have a play.</p>
dantag:danwebb.net,2007-10-07:24362007-10-07T23:38:00Z2007-12-21T23:41:28ZCustom Attributes And Class Names<p>At the Rich Web Experience, Alex Russell did a presentation entitled <a href="http://alex.dojotoolkit.org/?p=622">Standards Heresy</a>, In the presentation, which I didn’t attend so forgive me if I’ve gotten the wrong end of the stick, he spoke about how Dojo has been forced to abandon web standards in some cases in order to get the job done. The conversation was furthered by <a href="http://www.easy-reader.net/archives/2007/09/10/alex-russell-is-not-a-heretic/">Aaron Gustafson’s response</a> and is a really interesting discussion. However, I’m not going to comment on the politics of the <span class="caps">W3C</span> further as I know nothing about that at all. One example in the presentation reminded me of something I’ve wanted to comment on for a while now. Here’s that example:</p>
<pre><code class="html"><div dojoType="dijit.form.HorizontalSlider"
name="horizontal1"
onChange="dojo.byId('slider1input').value=arguments[0];"
value="10"
maximum="100"
minimum="0"
showButtons="false"
intermediateChanges="true"
style="width:50%; height: 20px;"
id="slider1">
...
</div></code></pre>
<p>At the Rich Web Experience, Alex Russell did a presentation entitled <a href="http://alex.dojotoolkit.org/?p=622">Standards Heresy</a>, In the presentation, which I didn’t attend so forgive me if I’ve gotten the wrong end of the stick, he spoke about how Dojo has been forced to abandon web standards in some cases in order to get the job done. The conversation was furthered by <a href="http://www.easy-reader.net/archives/2007/09/10/alex-russell-is-not-a-heretic/">Aaron Gustafson’s response</a> and is a really interesting discussion. However, I’m not going to comment on the politics of the <span class="caps">W3C</span> further as I know nothing about that at all. One example in the presentation reminded me of something I’ve wanted to comment on for a while now. Here’s that example:</p>
<pre><code class="html"><div dojoType="dijit.form.HorizontalSlider"
name="horizontal1"
onChange="dojo.byId('slider1input').value=arguments[0];"
value="10"
maximum="100"
minimum="0"
showButtons="false"
intermediateChanges="true"
style="width:50%; height: 20px;"
id="slider1">
...
</div></code></pre>
<p>This is a snippet of code showing how Dojo is going off the standards rails by adding custom attributes that are ‘needed’ to configure a slider widget. This is a really good example of a case where you definitely shouldn’t add custom attributes to <span class="caps">HTML</span>. While the <span class="caps">W3C</span>/browser vendors/whipping boy of choice might be letting us down what the web standards movement taught us (most importantly in my mind) is that semantic <span class="caps">HTML</span> is critically important. Having a <div> with custom attributes that tell Dojo it’s a slider widget is of no use to anything apart from as a crutch to Dojo. It has no semantic value at all. Outside of the context of Dojo it’s just an useless lump of markup.</p>
<p>Although <span class="caps">HTML</span> is a pretty limited vocabulary which is very document centric we can still go much further than this in attempting to describe what this is semantically. It’s an input so use an input or a select box as the base element. How browsers and assistive technologies deal with these elements is a lot closer to what we want than a meaningless <div>. Secondly, there’s custom attributes – having attributes containing behavioural information like showButtons and intermediateChanges are equally as semantically useless as the old presentational attributes like bgcolor and border and we’ve all learnt the disadvantages of mixing content and presentation and discarded those…hopefully. There’s got to be a better way.</p>
<p>So we want our semantic <span class="caps">HTML</span> and to keep our behaviour data out of our document. Take a leaf out of <span class="caps">CSS</span>’s book. We can name and classify objects and use these as our hooks to attach our JavaScript powered behaviour. Eureka! Not quite:</p>
<pre><code class="html"><!-- Created with http://cow.neondragon.net/stuff/reflection/reflectomatic.html -->
<img src="/reflection/photos/giraffe.jpg" width="132" alt="" class="reflect ropacity71" /></code></pre>
<p>The above code is from a nice little JavaScript effects library called <a href="http://cow.neondragon.net/stuff/reflection/">reflection.js</a> which uses
class names to hook in it’s behaviour unobtrusively. However, take a closer look at the class names. They aren’t classifying things as such, they are embedding configuration into directly into the class names. In a similar way it’s not a generally thought of as a good idea to give elements class names like ‘bigred’ or ‘width40’ although, depressingly, I’ve seen it done! This is definitely an abuse of class names – its not a ‘bigred’ its a ‘price’ and so on. This is seen not just in reflection.js but a large amount of ‘unobtrusive’ libraries.</p>
<p>So how can we improve on this? We need to provide configuration information to our JavaScript but neither custom attributes or embedding info are looking good. The answer is pretty simple – add another link to the chain and this is were (plug imminent :) projects like <a href="http://www.bennolan.com/behaviour/">behaviour.js</a> and <a href="/lowpro">Low Pro</a> come in. They add that other link to the chain. We can say that all inputs with the class ‘date’ should have a date selector attached to them or that selects with the class ‘rating’ should be replaced with a slider that’s range is 0-10 and so on. Here’s a snippet using Low Pro to illustrate this:</p>
<pre><code class="javascript">Event.addBehavior({
'select.rating': Slider({ min: 0, max: 10, intermediateValues: true }),
'input.date': DateSelector
});</code></pre>
<p>In this way we are able to maintain semantic <span class="caps">HTML</span>, avoid adding custom attributes and maintain a very loose coupling between our document and it’s behaviour. This, we’ve seen from <span class="caps">CSS</span>, is vitally important to maintainability and a real advantage. Via this method you can apply configuration to single items or as a group. If you decided that ‘rating’ selects should in fact all be vertical sliders instead of horizontal then that’s no problem either. It gives you ultimate flexibility.</p>
<p>This methodology is right at the core of Low Pro and I’ve been getting incredible results from it. It’s made what could be really complex JavaScript implementations a breeze. Instead of a huge, fearsome application everything becomes a <span class="caps">HTML</span> document with many loosely, coupled smaller components attached to it. If you don’t use Prototype/Low Pro don’t let that stop you from working this way. <a href="http://www.meme-rocket.com/2007/09/07/agnostic-unobtrusive-javascript/">Bill Burcham wonders whether this can be library agnostic</a>. Well, as an idea, in a sense it already is. All you need is the ability to select by <span class="caps">CSS</span> selectors. Dojo and dijit are in fact very well suited.</p>
dantag:danwebb.net,2007-07-18:23282007-07-18T14:30:00Z2007-07-18T14:32:45ZLow Pro Behaviours 101: Part 2<p>In the first post I briefly explained how to use pre-made Low Pro behaviours but, although I’m in the process of <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/">writing a few myself</a>, Low Pro is not going to be a widget library – what it is is a great framework to write your own components with. So, in this post, I’m going to go into a little detail about how to write your own behaviours. If the idea of that doesn’t bore your rigid then read on…</p>
<p>In the first post I briefly explained how to use pre-made Low Pro behaviours but, although I’m in the process of <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/">writing a few myself</a>, Low Pro is not going to be a widget library – what it is is a great framework to write your own components with. So, in this post, I’m going to go into a little detail about how to write your own behaviours. If the idea of that doesn’t bore your rigid then read on…</p>
<h3>Creating a behaviour</h3>
<p>As discussed in the last post behaviours are actually just specialised constructor functions. So, to create our behaviour we use Behavior.create in a very similar way to Class.create:</p>
<pre><code class="javascript">var Hover = Behavior.create();</code></pre>
<h3>Adding methods and properties</h3>
<p>This creates an empty behaviour much the same as Class.create gives us an empty class. Now we add our methods on to the prototype of the constructor that we’ve created. This example is a super simple behaviour, Hover, that will add/remove a class name (which you can specify) on mouse over/out:</p>
<pre><code class="javascript">Object.extend(Hover.prototype, {
initialize: function(className) {
this.className = className || 'over';
},
onmouseover: function() {
this.element.addClassName(this.className);
},
onmouseout: function() {
this.element.removeClassName(this.className);
}
});</code></pre>
<p>Any on* methods are bound as event handlers to the element when the behavior is attached to the element. The scope of these methods is ‘corrected’ automatically so that this will always refer to the behaviour instance. The behaviour instance also has a magic property, this.element, which points to the element it is attached to. The final thing you need to know is that the initialize method is called as soon as the <span class="caps">DOM</span> is ready (as soon as the element is available). We can now use this behaviour in the manner discussed in the last post:</p>
<pre><code class="javascript">Event.addBehavior({
'.dongle': Hover('hover')
});</code></pre>
<p>Aside from these special cases behaviour constructors are identical to any regular JavaScript ‘class’. You can add methods and properties as you see fit. Note that each element that has the behaviour attached to it gets its own instance of the behaviour so you can maintain the state of each behaviour independently without having to resort to setting expandos on the element, using closures or any other method which is messy and prone to causing those nasty circular references that cause memory leaks. As an alternative you can just pass your methods straight into the Behavior.create call so the following is equivilent to the above code:</p>
<pre><code class="javascript">var Hover = Behavior.create({
initialize: function(className) {
this.className = className || 'over';
},
onmouseover: function() {
this.element.addClassName(this.className);
},
onmouseout: function() {
this.element.removeClassName(this.className);
}
});</code></pre>
<h3>Working with multiple elements</h3>
<p>Now this is all good for dealing with behaviours that work on a single element but in many cases we want a behaviour to operate on a number of elements. For example, you would want to be able to attach a Sortable behaviour to a list element but the behaviour itself would also need to deal with all the list element inside it. There are a number of ways to approach writing these kind of behaviours, all of which are demonstrated in the various test behaviours I’ve written.</p>
<h4>Event delegation with behaviours</h4>
<p>The first technique, and normally the best is using event delegation to capture all the events on elements inside the attached element with your behaviour and process them. The process is pretty simple…here’s part of the <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/date_selector.js">Calendar</a> behaviour:</p>
<pre><code class="javascript">var Calendar = Behavior.create({
// other methods hidden for clarity
onclick : function(e) {
var source = Event.element(e);
Event.stop(e);
if ($(source.parentNode).hasClassName('day')) return this._setDate(source);
if ($(source.parentNode).hasClassName('back')) return this._backMonth();
if ($(source.parentNode).hasClassName('forward')) return this._forwardMonth();
}
});</code></pre>
<p>Here, we define a single onclick method which will capture clicks on all the elements inside the calendar – Forward and back arrows, and the dates themselves. Firstly, we use Event.element to grab the source element, the element that was actually clicked, then we can just examine this element to work out what needs to happen to the calendar and call the relevent method. In this case, and in most cases, the most convenient way is to look at what class names the element has. In the calendar, each day has the class ‘day’ and the forward/back arrows have the classes ‘forward’ and ‘back’. This method is really nice for a number of reasons, firstly, we avoid attaching lots of event handlers for each sub element and secondly we have this central point where we can handle and dispatch events – a really pleasant way to work with complex interactions. Of course, event delegation isn’t always a good fit so…</p>
<h4>Linking behaviours</h4>
<p>In more complex cases when the sub elements of your behaviour need to maintain their own state or handle events in a more complex way you can have your main behaviour attach sub-behaviours to inner elements during initialisation and maintain a link between the two. An example of this can be seen in the <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/draggable.js">Draggable</a> behaviour:</p>
<pre><code class="javascript">Draggable = Behavior.create({
initialize : function(options) {
// code hidden for clarity
this.handle = this.options.handle || this.element;
new Draggable.Handle(this.handle, this);
}
// code hidden for clarity
});
Draggable.Handle = Behavior.create({
initialize : function(draggable) {
this.draggable = draggable;
},
onmousedown : function(e) {
// code hidden for clarity
}
});</code></pre>
<p>Here, the initialize method of Draggable finds the element that it wants to be the ‘drag handle’ and attaches another behaviour, Draggable.Handle, to it. At this point we pass a reference to the Draggable instance to the Draggable.Handle instance so the drag handle can refer back to and control the main draggable behaviour. You can of course, if necessary, build up a complex component by building a number of linked behaviours that all comunicate back to the main behaviour.</p>
<h3>Get it? Got it? Good</h3>
<p>So that’s all for now. Any questions just drop me a comment and I’ll get back to you <span class="caps">ASAP</span>. At this point, if you are interested in writing your own behaviours then it would be worth referring to the <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/">behaviours in <span class="caps">SVN</span></a>. However, I’m just feeling this out for myself and I’m sure I’ve not explored any near all of the possibilities of working with behaviours so if you have any brain waves be sure to post a comment also. If there’s enough interest I might include a behaviours repository on the upcoming Low Pro site.</p>
dantag:danwebb.net,2007-07-17:23182007-07-17T01:02:00Z2007-07-17T02:18:59ZLow Pro Behaviours 101
<p>Okay, I’ve gone on about this for long enough and made lots of promises. So now’s time to make a start on explaining all this business with Low Pro and ‘behaviours’.</p>
<p>Behaviours are part of Low Pro and are object orientated mechanism by which you can handle events and maintain the state of an element (or indeed a set of elements) and as I’ve found out recently are an incredibly nice way of writing and deploying UI widgets. Before I dive in to how to write your own behaviours, let’s get a flavour for how to use them. If you want to play along you’ll need the latest versions of Prototype and Low Pro as well as the remote behaviours which you can <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/remote.js">grab from my <span class="caps">SVN</span></a>.</p>
<p>The first thing to note about a behaviour is that they are simply specialised constructor functions so you can use them with the new keyword to create an instance:</p>
<pre><code class="javascript">var aLink = $('edit_5');
var ajaxLink = new Remote.Link(aLink, { method: 'post' });</code></pre>
<p>Behaviours, when used with the new keyword, always take an element reference as the first argument. Any subsequent arguments are passed to the behaviours constructor. In the case above, Remote.Link is a behavior which when attached to a link will make the link trigger an Ajax request rather than a tradtional page refresh. With this behaviour the second argument is an options hash that is passed through to the Ajax request. Now we’ve created an instance of the behaviour that instance of the behaviour is bound to that element for it’s life time on the page handling click events on the link and sending Ajax requests.</p>
<p>If you need to attach a behaviour to multiple elements on then using new could get a little tedious. To this end behaviours work very nicely with Event.addBehavior:</p>
<pre><code class="javascript">Event.addBehavior({
'a.edit': Remote.Link
});</code></pre>
<p>Using a behaviour with Event.addBehavior in this way will attach a seperate instance of the behavior to every element that matches the <span class="caps">CSS</span> selector. Notice we don’t pass in an event in the selector as you might be used to. The behaviour knows what events it wants to listen for. Now all the links in the page with the class name ‘edit’ will invoke Ajax request. You may need to pass in extra information to the behaviour as we did above with the options hash. Thanks to a bit of metaprogramming hackery we can do this too:</p>
<pre><code class="javascript">Event.addBehavior({
'a.edit': Remote.Link({ onComplete: triggerEdit })
});</code></pre>
<p>As you can see, it’s almost like <span class="caps">CSS</span> for interactivity where you’re defining how elements behave in an declaritive, almost code-less fashion. In my own projects I’ve gained massive advances in maintainability by separating everything out into behaviours then using Event.addBehavior as the glue to my <span class="caps">HTML</span>. You don’t need to use custom <span class="caps">HTML</span> attributes or weird classnames – you just bind behaviours to elements as you would style rules in <span class="caps">CSS</span>.</p>
<p>Of course, using this method you don’t get references to the behaviour instances you’ve created. In fact, you’ll hardly ever need to get references to these behaviour instances as most behaviors don’t need public methods at all but in case you need to get at them there’s a property of each behavior that contains an array of all its instances on the page:</p>
<pre><code class="javascript">Remote.Link.instances //=> an array of all the instances of Remote.Link</code></pre>
<p>So that’s basically how to use behaviours. In a day or two I’ll post part two of Behaviours 101 which will show you how to make your own but in the meantime try out some of the behaviours I’ve already created. So far there’s a Draggable, Droppable, A date picker, Remote link and Remote form. Check out the <a href="/behavior_demo/">demo page</a>.</p>
dantag:danwebb.net,2007-06-16:20642007-06-16T15:19:00Z2007-06-17T03:29:15ZThe State (And Future) Of The UJS Plugin<p>Over the past few weeks loads of people have been asking me about what’s going on the <span class="caps">UJS</span> plugin. It’s obviously fallen in to disrepair so people, understandably, have been concerned. There has been a reason for this aside from the fact that I am a lazy barsteward (which of course I am, but that’s beside the point). Here is a letter I’ve just written to the <span class="caps">UJS</span> mailing list that I’d thought I’d post here to try to get a little more feedback. It’s a little bit long but bear with me…</p>
<p>Over the past few weeks loads of people have been asking me about what’s going on the <span class="caps">UJS</span> plugin. It’s obviously fallen in to disrepair so people, understandably, have been concerned. There has been a reason for this aside from the fact that I am a lazy barsteward (which of course I am, but that’s beside the point). Here is a letter I’ve just written to the <span class="caps">UJS</span> mailing list that I’d thought I’d post here to try to get a little more feedback. It’s a little bit long but bear with me…</p>
<p>I’ve been chatting to Luke and users of <span class="caps">UJS</span> about what to do with it and still haven’t quiet decided hence the lack of news but below is a rundown of where we are at on the whole thing. However, this is definitely personal opinion and doesn’t necessarily represent Luke’s opinion on the matter.</p>
<p>Essentially, the status is that, of late, I personally have not used <span class="caps">UJS</span> at all and have found a much better process by using Low Pro on its own without all the Ruby scaffolding of the <span class="caps">UJS</span> plugin. Secondarily, after talking to lots of developers at RailsConf it seems that the <span class="caps">UJS</span> plugin has failed to truly achieve it’s main goal which is to get Rails developers to write JavaScript using progressive enhancement. Many people seem to mainly use the plugin to get their JavaScript in to a separate file which is actually not even essential to progressive enhancement and I think this is a failing in the design of <span class="caps">UJS</span> itself. To achieve progressive enhancement you really need to think of JavaScript as a separate layer on top of a working <span class="caps">HTML</span> application but <span class="caps">UJS</span> lets you get away with keeping behavior in your views and hence leads many developers to think in the same way as they did before but think they are unobtrusive because they don’t see any JavaScript in their <span class="caps">HTML</span> – which is obviously not what we wanted to achieve. While many people can and do successfully use <span class="caps">UJS</span> for progressive enhancement even more seem not to – <span class="caps">UJS</span> has not been the ‘angel on your shoulder’ that I originally wanted it to be.</p>
<p>On top of this, the method by which the generated JavaScript is kept in the session has many limitations which myself and Luke have been aware of from the start. It’s not generally a good idea to keep this much information in the session (in fact, normally I never store more than a user ID if I can help it) and while acceptable for light to medium use it does have an upper limit depending on the type of session storage you are using. Rails edge now uses cookies to store session info by default which have a very very low limit which will cripple <span class="caps">UJS</span> completely. We have considered other alternatives such as some kind of file based storage but every time it just strikes me as too much scaffolding just to allow developers to put behavior in their view files which, as a said above, I’ve come to believe is a really bad idea anyway.</p>
<p>One of the things that I do personally like and something that has received the most positive feedback are the behavior helpers (the make_*) stuff which essentially encapsulate common tasks with sensible defaults in a very Rails like way. It’s a real time saver and the conventions provided mean that the best path (such as using this.href for the Ajax url) is the easiest. Recently, I’ve come to do this in my own projects via Low Pro and it’s behavior ‘classes’ (although they need a better name!). Now via Low Pro I can write stuff like:</p>
<pre><code class="javascript">Event.addBehavior({
'.product a.description' : Remote.Link({ update : 'product_description' }),
'.product' : Draggable({ revert : true }),
'#basket' : Droppable
});</code></pre>
<p>I really like this and am slowly building up a library (which you can see if you look at the <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviors/">Low Pro trunk</a>) of common behaviors. There’s a date picker, a drag/drop implementation and the remote stuff I’ve illustrated above. I’m planning on writing autocompleters and in-place editors as behaviors as well. But behaviors have proven really easy to write and I love them as a tool for building site specific components. In fact, as I’ve worked with Low Pro it’s become apparent to me that behaviors are by far the killer feature which is interesting as they were just an experiment I hacked together one day without much thought.</p>
<p>So what to do? Well, there’s two ways to go as far as I can see. The first is to shut down development on <span class="caps">UJS</span> completely (or hand it over to another party if anyone is interested) and go on to promote the techniques of implementing progressive enhancement using Low Pro that I’ve found to be so successful recently. This could possibly be via the UJS4Rails site or through my own site – I’m not sure which would be a better platform right now.</p>
<p>The other would be to re-think the <span class="caps">UJS</span> plugin totally and go for some kind of 2.0 release that would take a completely different tack. However, all of the ideas for this I’ve thought of or heard so far don’t really compel me to write them. I think to work on this myself I’d need to be sure that I’d want to use it and so far this is not the case but any ideas and feedback are very welcome so please do drop me a mail or feedback on this list.</p>
<p>Either way, we need to make fixes to the current plugin to make it work with Rails 1.2.3 which I’ve been working on recently but I’d love patches if you’ve already solved these issues yourself (which it appears many of you have).</p>
<p>So yes, that’s it. Let me know what you think, I’d appreciate any feedback you have.</p>
dantag:danwebb.net,2007-04-16:16692007-04-16T10:08:00Z2007-05-20T00:32:06ZLow Pro 0.4 Released
<p>I’m back from India and just dropping a quick note to say that Low Pro 0.4 is out. There are a few new features (which I’ll go into later) but essentially this is a bug fix / optimisation release and has many changes that help it work well with the <a href="http://prototypejs.org/download" title="1.5.1 RC2">latest version of Prototype</a>. Most of this has been backing out parts of Low Pro that have been implemented or otherwise bettered in Prototype now which is great and I expect to see more of this happening soon. There’s some good work going on with events at the moment and <span class="caps">DOM</span> ready support is planned to go in soon.</p>
<p>One feature of Low Pro I have been using heavily myself are Behaviour classes. Behaviour classes allow you to attach behaviour to elements in an object orientated way. Each element gets it’s own instance of the behaviour which means that it can retain state through its lifetime without using expandos or creating nasty circular references that cause memory leaks (well, of course, you still can but it lessens the chances). I intend to write a lot more about behaviour classes shortly but in the meantime have <a href="http://svn.danwebb.net/external/lowpro/trunk/behaviours/draggable.js">a peek at the Draggable behaviour in <span class="caps">SVN</span></a> it turns out that it’s a really neat way to write components.</p>
<p><a href="http://svn.danwebb.net/external/lowpro/tags/rel-0.4/dist/">Download Low Pro 0.4</a></p>
dantag:danwebb.net,2006-09-03:462006-09-03T09:34:00Z2007-05-20T00:32:35ZLow Pro: Unobtrusive Scripting For Prototype<p>Low Pro is a set of extensions to the Prototype library that make it easier to implement unobtrusive <span class="caps">DOM</span> scripting and forms the JavaScript component of the <a href="http://www.ujs4rails.com">Unobtrusive JavaScript Plugin For Rails</a> but can be used separately. It’s essentially a compilation of various tried and tested, previously published techniques adapted for use with Prototype and mainly centres around enhancing event handling and <span class="caps">DOM</span> manipulation. Low Pro uses portions of code and/or inspiration from <a href="http://dean.edwards.name">Dean Edwards</a>, <a href="http://www.outofhanwell.com/blog/">Matthias Miller</a>, Sylvian Zimmer, <a href="http://www.encytemedia.com">Justin Palmer</a> and <a href="http://www.ejohn.org">John Resig</a>.</p>
<p>To start out with Low Pro, <a href="http://svn.danwebb.net/external/lowpro/tags/rel-0.2/dist/lowpro-0.2.zip">download the 0.2 distribution from my Subversion repository</a> and included it along with the Prototype JavaScript file. Low Pro depends on Prototype so don’t forget to include it first:</p>
<pre><code class="html">&lt;script src="/js/prototype.js" type="text/javascipt"&gt;&lt;/script&gt;
&lt;script src="/js/lowpro.js" type="text/javascipt"&gt;&lt;/script&gt;</code></pre>
<p>In the distribution is a standard commented version and a compressed version. Now for a quick tour of the features.</p>
<p>Low Pro is a set of extensions to the Prototype library that make it easier to implement unobtrusive <span class="caps">DOM</span> scripting and forms the JavaScript component of the <a href="http://www.ujs4rails.com">Unobtrusive JavaScript Plugin For Rails</a> but can be used separately. It’s essentially a compilation of various tried and tested, previously published techniques adapted for use with Prototype and mainly centres around enhancing event handling and <span class="caps">DOM</span> manipulation. Low Pro uses portions of code and/or inspiration from <a href="http://dean.edwards.name">Dean Edwards</a>, <a href="http://www.outofhanwell.com/blog/">Matthias Miller</a>, Sylvian Zimmer, <a href="http://www.encytemedia.com">Justin Palmer</a> and <a href="http://www.ejohn.org">John Resig</a>.</p>
<p>To start out with Low Pro, <a href="http://svn.danwebb.net/external/lowpro/tags/rel-0.2/dist/lowpro-0.2.zip">download the 0.2 distribution from my Subversion repository</a> and included it along with the Prototype JavaScript file. Low Pro depends on Prototype so don’t forget to include it first:</p>
<pre><code class="html">&lt;script src="/js/prototype.js" type="text/javascipt"&gt;&lt;/script&gt;
&lt;script src="/js/lowpro.js" type="text/javascipt"&gt;&lt;/script&gt;</code></pre>
<p>In the distribution is a standard commented version and a compressed version. Now for a quick tour of the features.</p>
<h3><span class="caps">DOM</span> navigation and manipulation</h3>
<p>As Prototype’s <span class="caps">DOM</span> manipulation is very innerHTML centred Low Pro adds few useful methods to elements to help you navigate and manipulate the <span class="caps">DOM</span> in the nice clean <span class="caps">W3C</span> way.</p>
<pre><code class="javascript">$('doomed').remove(); // removes the element from the DOM and returns it
$('item').nextElement(); // returns the next element in the document (excluding text nodes)
$('item').previousElement(); // guess...
$('thing').insertAfter(element); // the DOM gives you insertBefore but not this
$('bong').replaceElement(element); // replaces an element and returns the substitute</code></pre>
<p>You can get to all of these methods via the <span class="caps">DOM</span> object as well.</p>
<pre><code class="javascript">DOM.remove(element);
DOM.insertAfter(oneElement, anotherElement);</code></pre>
<p>Also, Low Pro aids you in creating node structures via the <span class="caps">DOM</span> with a Prototype version of <span class="caps">DOM</span> Builder. Each <span class="caps">HTML</span> tag has a builder function called $[tag]. You can nest these to create complex <span class="caps">DOM</span> structures easily.</p>
<pre><code class="javascript">var listItem = $li({ id : 'item-1' },
$strong("Some text")
);
// returns a node equivilent to: &lt;li id="item-1"&gt;&lt;strong&gt;Some text&lt;/strong&gt;&lt;/li&gt;
$('a_list').appendChild(listItem);</code></pre>
<p>Read more about <span class="caps">DOM</span> builder over at <a href="http://www.vivabit.com/bollocks/2006/04/06/introducing-dom-builder">The Web’s Bollocks</a>.</p>
<h3>Events</h3>
<p>The event handling code in Prototype is one of it’s weakest points so Low Pro replaces out Event.observe() and Event.stopObserving() totally with a version of Dean Edwards’ addEvent() and removeEvent() routines. This offers much more consistency across browsers and a few neat fixes:</p>
<pre><code class="javascript">Event.observe('thing', 'click', function(e) {
this.hide() // this refers to the triggering element.
return false; // stops the default behaviour (even in Safari!)
});</code></pre>
<p>All other methods remain backwards compatible. For convenience, observe() and stopObserving() are mixed in to elements. A trigger method is also provided to allow you to trigger event handlers programmatically.</p>
<pre><code class="javascript">Event.trigger(element, 'click');</code></pre>
<p>Event.onReady() allows you to stack up callbacks that will trigger as soon as the <span class="caps">DOM</span> is ready rather than onload which triggers after the whole page is loaded.</p>
<pre><code class="javascript">Event.onReady(function() {
$('thing').visualEffect('highlight');
});</code></pre>
<p>Repeated calls will simply stack up callbacks.</p>
<h3>Behaviours</h3>
<p>Low Pro adds declaritive behaviours to Prototype. Event.addBehavior() allows you to specify element behaviours via <span class="caps">CSS</span> selectors.</p>
<pre><code class="javascript">Event.addBehavior({
'a.todo:click' : function(e) {
new Ajax.Request('todo/add', ... );
},
'div.feature:mouseover' : function(e) {
this.hide();
}
});</code></pre>
<p>These behaviours are applied as soon as the <span class="caps">DOM</span> is loaded and are reapplied to new elements after Ajax calls. An alternative more OO approach is to create a Behaviour ‘class’ which can be attached to elements. Each element gets it’s own instance of the behaviour class that retains it’s state throughout the life of the page. Within behaviour classes, this.element always points to the attached element.</p>
<pre><code class="javascript">var Resize = Behavior.create({
initialize : function() {
// gets called when the element is loaded.
},
onclick : function(e) {
// use on methods to set event handlers on a object
}
});</code></pre>
<p>Finally, I’ve included Sylvian Zimmer’s optimisation of the $$ selector which speeds up node selections quite dramatically. It is, in my experience, a little bit buggy though so if you encounter problems you can revert to the normall $$ code.</p>
<pre><code class="javascript">LowPro.optimize$$ = false;</code></pre>
<p>So, that’s it. Any feature suggestions are much appreciated as are bug reports. Please log them on <a href="http://projects.danwebb.net/newticket">my Trac</a> and I’ll fix them <span class="caps">ASAP</span>.</p>
<p><strong><span class="caps">UPDATE</span></strong>: Low Pro is compatible with any of the Prototype 1.5 releases but will not work with 1.4 or below.</p>