Subscribe: danwebb.net - Home
http://www.danwebb.net/feed/atom.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
behavior  code  content  data  event  function  it’s  i’ve  jquery  low pro  low  new  pro jquery  pro  prototype  web 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: danwebb.net - Home

danwebb.net - Home





Updated: 2011-05-29T04:40:43Z

 



It's About The Hashbangs

2011-05-29T04:40:43Z

Before I get started here’s the disclaimer: The opinions expressed in this rant are my own personal opinions on web development and do not represent the views of my employer, its engineering organisation or any other employees. A few months back there was a flurry of blog posts and conversations over Twitter both for and against the now fairly common practice of using hashbang urls (example) and JavaScript routing in favor of traditional URLs and full page loads. There is also growing interest around several JavaScript MVC frameworks that are make heavy use of this technique. Since people started doing this kind of thing I’ve been pretty squeamish about the idea. At the time that this discussion erupted across the web I really wanted to comment on it but until recently, although I was almost certain that hashbang URLs were destructive, I found myself unable to put in definite terms why. As you probably know if you’ve been reading this blog for a while, I have for a long time been an avid proponent of progressive enhancement and as many people correctly pointed out many of the arguments against hashbang URLs seemed to fold this philosophy in which clouded the issue quite a lot. In a well reasoned post, my colleague, Ben Cherry pointed this out and expressed that it wasn’t really hashbangs that were the problem and that they were merely a temporary work around until we get pushState support. As he put it, “It’s Not About The Hashbang”. After quite a lot of thought and some attention to some of the issues that surround web apps that use hashbang URLs I’ve come to conclusion that it most definitely is about the hashbangs. This technique, on its own, is destructive to the web. The implementation is inappropriate, even as a temporary measure or as a downgrade experience. Let me explain. URLs are important. The reason the web is so powerful is that it is a web of information. Any piece of content can reference any other piece of content directly. Our information is no longer siloed into various disconnected libraries, now all our data is linked together. The web is much better at doing this than as a platform for delivering applications but yeah, that’s a whole other blog post. The means by which one piece of data is linked with another piece of data is via a URL. That makes the URL possibly the most important part of the web. If you are working on a web app I assume you value its content. If you value the content that a web app holds then you need to value it’s URLs even more. Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs. URLs are forever. The web has a pretty long memory. Techniques and technology may change but content published to the web gets indexed, archived and otherwise preserved as do the URLs that they link to. There’s no such thing as a temporary fix when it comes to URLs. If you introduce a change to your URL scheme you are stuck with it for the forseeable future. You may internally change your links to fit your new URL scheme but you have no control over the rest of the web that links to your content. Cool URLs don’t change. For this and other reasons, Tim Berners-Lee wrote a classic article, Cool URLs don’t change in which he explains how to make future proof URLs and why that is important. If you change your URLs you sever links with from the rest of the web. You’ve just turned your web app into a data silo. Your content has just become a lot less useful. However, as much as we try it’s pretty impossible not to introduce change from time to time, sometimes data does need to be deleted, sometimes you need to move to a new domain name, sometimes you just need to reorganise. Luckily, HTTP gives us the tools to handle this gracefully. If content is deleted we can tell the web it’s no longer there with a 410 (thanks Nick!), if it’s moved to a different place on the web we can tell the world its new location with a 301 or a 302. HTTP gives us the ability to manage ch[...]



Writing a new library? Sketch it out first

2011-02-10T05:53:35Z

So you’re embarking on writing a new library. You might dive right in to the code and work straight on solving the problem or you might take a more considered approach and start thinking about how to model the problem, what classes and methods you need to create, how they interact and so on. However, rather than doing that why not start with sketching out not how the library works but how you would like it to be used. I think you’ll see pretty positive results if you try it. Usability isn’t just for designers. If you want your co-workers or other developers to use and be productive with this code your creating its got to be as simple and fun to use as your user interfaces. Your library’s API is a user interface. History has shown that libraries and open source projects that put their API design up front are far more successful than their competitors. Take jQuery for instance, you can bet that when John sat down to create jQuery he wasn’t thinking “How do I animate CSS style?” or “How do I create and event system?” his main concern was how he wanted jQuery to be used. At least initially, the internals of jQuery were a mish mash of various libraries that came before it. What actually powered the explose growth of jQuery was the revolutionary API concepts it introduced: Method chaining, Selector-focussed API, simple plug in interface and so on. Other success stories like Ruby on Rails shared a similar focus on API design. So, how do you write your code in such a way that it will make programmers happy and propell you into internet stardom? When you start out writing a new library or feature, start with a sketch. Cast aside any ideas that you might have already have about the implementation details and try to also cast aside any technical constraints and just start writing how you’d like your code to be used. Let’s take a DOM builder, for example. Mashing strings (or indeed using the terribly designed W3C DOM API) is no fun in JavaScript. If you were taking an implementation first approach you might start with an JSON-style data structure describing your DOM fragment or maybe even consider a set of objects that map to the various types of elements and this may well be how you implement it under the hood but put that aside for now. How would your code look when using the library? Here’s my first pass: var fragment = build( div({ id: 'contact' }, ul( li('Email: whatever@thing.com'), li('Twitter: ', a({ href: 'http://twitter.com/danwrong' }, '@danwrong')) ) ) ); Come up with the simplest, most aesthetically pleasing API you can and keep itterating on it until you’ve weeded out all the complexity you can. If certain arguments are optional or have a sensible defaults then make sure that the developer doesn’t have to worry about them unless they need to, is your library similar to any other library? If it is maybe its worth adopting the conventions of that library so it acts in a way that other developers expect it to. Developers dislike like reading documentation as much as your site’s users dislike read help pages. Strive for an API so simple that you can describe it in a few sentences. Once you are happy with your sketch start building it out. You might need a little meta programming magic to realise the UI you are going for and that’s fine but use with caution. You need to weigh up whether the magic you are adding is going to make your code act in a way that is unpredictable to developers used to working with the language in question or if it will prevent developers from using their existing knowledge of the language to solve problems with your code. If you smell badness then leave the magic behind. In our example above we need to do quite a bit of work with the function arguments in order to support variable amounts of child nodes and to allow optional attribute hashes. In this case I’d make the call that this doesn’t add any extra confusion to the code so I’m happy to go with that. Also[...]



Added OEmbed and Embeddable Player to twaud.io

2010-05-26T13:25:10Z

I’ve just added OEmbed to twaud.io for fun and profit. I’d not really looked into it until Dustin and Russ pointed out and I really like the idea although it seems a bit under done at the moment (You can only have ‘image’, ‘video’ or ‘rich’ as media types. What about audio?). I’ve been meaning to implement an embeddable player for twaud.io for a long time so I decided to add them in.

The OEmbed endpoint is:

http://twaud.io/oembed.{format}

It supports JSON, XML and JSON-P (if you provide a callback parameter to a json request). For example:

http://twaud.io/oembed.json?url=http%3A%2F%2Ftwaud.io%2FYf&callback=myCallback

Returns this:

myCallback({
  "height":"65",
  "provider_url":"http://twaud.io",
  "title":"Little mix of all the dubstep tunes I've been listening to lately: WRONG BEAT",
  "type":"rich",
  "html":" allowtransparency='true' frameborder='0' scrolling='no' src='http://twaud.io/embed/Yf' style='width: 395px;  height: 65px; border: none;'>\n",
  "audio_type":"audio/mpeg",
  "audio_url":"http://twaud.io/audio/Yf",
  "width":"395",
  "author_name":"danwrong",
  "version":"1.0",
  "author_url":"http://twitter.com/danwrong",
  "provider_name":"twaud.io" 
});

The HTML property contains a snippet of HTML that renders the player:

src="http://twaud.io/embed/Yf">

All very beta at the moment but give it a try. Also, check the short dubstep mix I did a while back. Will post a longer one soon.




Put that data-* attribute away, son...You might hurt someone

2010-01-27T15:10:50Z

HTML 5 data-* attributes allow us to add custom attributes to elements as long as they are prefixed with ‘data-’ and since this was first discussed on John Resig’s blog I’ve been interested in how people will use and abuse this feature. I greeted the feature with mixed feelings. It’s definitely a simple way to enrich the semantic value of HTML pages as well as helping to improve some of the more toxic parts of Microformats. XML namespaces are definitely a more complete solution but this is a simple and immeadiately adoptable means to add invisible semantic data to HTML documents. However, as John hinted in his post, there’s an enormous temptation for JavaScript authors to use this to embed configuration data for their scripts directly into HTML. Many developers have been itching for an excuse to do this for a long time. Some just added attributes willy-nilly like crazy web standards bandits, some would love to do add arbiturary configuration into their HTML but felt a bit squeamish about moving away from the HTML specs and opted to abuse the class attribute from within the standard. For the record, I’d tend to side with the former. If it works and there’s a good reason for it then I say do it. However, back then I explained why there is no good reason to add unsemantic configuration data into your HTML and now that we have standards-approved carte-blanche to do this I’d like to reiterate that it’s still not the way forward. If you’ve not read that article then its worth a quick read before you go on. By all means, use data-* attributes to add semantically valuable data to your HTML but if you are just using it to prop up a script you are writing think again. An Example If you’ve not already watched it go now and watch Yehuda’s Screencast on evented programming with jQuery. The ideas in here represent a massive progression in client-side scripting. It’s nothing short of essential viewing. However, it also happens to be the latest example I’ve come across of needless use of data-* attributes and, while not wanting to take away from how progressive and clever the content is as a whole, I feel the need to use it as my counter-example for this article. In the screencast, Yehuda is creating a tab interface. The markup he proposes is something like this:
  • First
  • Second
  • Third
Some content
Some content
Some content
The idea being that when the tab
  • is clicked the script then interrogates data-content to decide which div to show. However, without the JavaScript operating on this the HTML has no semantical value. The
  • s are just list elements (and will be read as such by assistive technologies). In fact, the browser doesn’t know that those list elements are in anyway associated with
    s below. Here’s how I think it should be marked up:
    Some content
    Some content
    Some content
    Now, before we even add JavaScript we have links that we can click that will jump you to the specified content. If you click the back button you will jump back to t[...]



    Low Pro for Prototype and Firefox 3.5

    2009-07-02T11:32:57Z

    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 from GitHub

    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:

    (function() {
      var aFunction = function() {
        aFunction.thing = 47;
      };
    
      aFunction();
    
      alert(aFunction.thing); //=> 47;
    })();



    Massive Robot launches twaud.io

    2009-05-20T14:04:45Z

    Well, it’s been a bloody long while again since I’ve posted here and I suppose you’ve all unsubscribed me now. To be honest, I wouldn’t blame you.

    However, silence here does not mean that I’ve been sitting on my arse doing nothing. In fact, the reality is very much to the contrary. Loads of stuff has been going on but there are two new pieces of news. Firstly, I’ve renamed and rebranded my company. We are now Massive Robot and we are available for consultancy and development work so if you have anything in mind then please contact us. Joe has done the branding and it’s something I’m really pleased with.

    Check the business cards…

    (image)

    Along with those is a new site and a T-shirt. The final and most important Massive Robot branding will be the kicks. I’m working on those at the moment.

    (image)

    This week launched twaud.io, Massive Robot’s new service. The idea is simple – it’s like twitpic but for audio. Go to the site or use the API to upload your audio and you get a page with a short URL and a player for your followers to listen to it. This is just the start and we are working on a whole load of new features for it so follow @twaudio to keep up to date.

    The build of twaud.io has been an interesting and fun experience. I was able to use Twitter’s new OAuth based login process via twitter_auth which I’d recommend wholeheartedly for as a foundation for Twitter applications, although I have hacked to allow for both OAuth (for the site) and username/password based (for the API) authentication where normally you must choose one or the other. It also uses S3’s direct uploading facility via SWFUpload which was not easy to get going but has provided a really scalable system as the application stays completely out of the loop of the bulky upload process. I love the direction web development is moving in at the moment.




    It's Been A Long Time...

    2008-06-24T00:24:12Z

    But I’ve not just been sitting on my arse playing GTA IV, 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, Max, 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.

    Secondly, I’ve been hacking away nearly full time on one of my favourite projects to date, Peoples Music Store with LRUG stalwart and renowned anarchist, James ‘Bringing London To Its Very Knees’ Darling which is maturing nicely under private beta as we speak. Peoples Music Store is a great idea from some of the guys behind bleep.com 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.

    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 Rack. It simply is the dog’s bollocks.

    So, enough of the excuses. What’s on the horizon?

    Speaking and Conferences

    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 Jarkko Laine) at RailsConf Europe all about JavaScript related Rails stuff and I’m likely to have a slot at @media Ajax as well. Also, I’ll be heading to dConstruct as is the tradition.

    Hacking and Open Source Business

    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 Evil which is going to contain lots of Merb/Rack goodness. The first by-product of which is the merb_openid 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.

    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.




    Event Delegation Made Easy

    2008-03-07T21:06:20Z

    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 Christian and the guys at YUI started talking about it 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.

    In most instances I end up writing a lot of event handlers that look like this:

    $('#thing').click(function(e) {
      var target = $(e.target);
    
      if (target.hasClass('quit') return doQuitStuff();
      if (target.hasClass('edit') return doEditStuff();
      // and so on...
    });

    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:

    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));
      }
    }

    Using it is simple:

    $('#thing').click($.delegate({
      '.quit': function() { /* do quit stuff */ },
      '.edit': function() { /* do edit stuff */ }
    }));

    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:

    DateSelector = $.klass({
      onclick: $.delegate({
        '.close': function() { this.close() },
       '.day': function(e) { this.selectDate(e.target) }
      }),
      selectDate: function(dayElement) {
        // code ...
      },
      close: function() {
        // code ...
      }
    });

    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.

    UPDATE: 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:

    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));
        }
    }

    Meanwhile, you might want to take a look at the patch by Peter Michaux.




    How To Use Low Pro For jQuery

    2008-02-04T00:28:00Z

    It seems that my initial version of Low Pro for jQuery 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. Heh, let’s not call it that again. Bad. Anyway, on with the show… It seems that my initial version of Low Pro for jQuery 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. Heh, let’s not call it that again. Bad. Anyway, on with the show… Class-based OO 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 this article on the prototype site. The only difference is that instead of using Class.create you use $.klass: Draggable = $.klass({ initialize: function(options) { }, onmousedown: function() {} }); GhostedDraggable = $.klass(Draggable, { onmousedown: function($super) { // do extra stuff here then call original method... $super(); } }); Attaching the behavior class to elements To attach the behavior class to some elements you can use the attach method: $('div.product').attach(GhostedDraggable, { anOption: thing }); attach 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 initialize function. A few magic things happen here. First, this.element 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, this 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 this.element if you need to though. And for the bonus round… So, that’s about all there is to it. One added bonus is that if you are using livequery then Low Pro will automatically use it to attach any new behaviors after the DOM is changed without you needing to worry about it. Here’s a super simple example behavior that simply adds and removes a CSS class name when it is hovered over. It’s about as bare bones as you can get while showing off most of the features: 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'); }); For more information about how you might use behavior classes take a look at this article. 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 source 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 Low Pro list. [...]



    Low Pro For jQuery?

    2008-01-31T14:43:25Z

    A few days ago a discussion started about porting Low Pro over to jQuery. It’s been on my mind for a while (especially since Bill blogged about agnostic UJS) 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: Event.addBehavior({ 'a.external:click': function() { //...code...// }, 'div.product:mouseover': function() { //...code...// } }); Can be achieved in jQuery like this: jQuery(function($) { $('a.external').click(function() { //...code...// }); $('div.product').mouseover(function() { //...code...// }); }); 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)... A few days ago a discussion started about porting Low Pro over to jQuery. It’s been on my mind for a while (especially since Bill blogged about agnostic UJS) 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: Event.addBehavior({ 'a.external:click': function() { //...code...// }, 'div.product:mouseover': function() { //...code...// } }); Can be achieved in jQuery like this: jQuery(function($) { $('a.external').click(function() { //...code...// }); $('div.product').mouseover(function() { //...code...// }); }); 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)... 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. 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[...]



    How Good Is This?

    2008-01-02T14:07:11Z

    >> a = 79.99 * 100
    => 7999.0
    >> a.floor
    => 7998
    >> b = 7999.0
    => 7999.0
    >> b.floor
    => 7999

    I’ll tell you. It’s not good. I hate floating point calculations. Happy new year!




    danwebb.net Dunk Low

    2007-12-25T16:50:26Z

    (image)

    Thanks Catherine! The real things are on there way in a couple of weeks. Happy Christmas, Peeps.




    Low Pro 0.5: Now Compatible With Prototype 1.6

    2007-12-13T17:49:59Z

    Today I tagged Low Pro 0.5 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 DOM nodes and a lot more). It’s also got a couple of new features so here’s a rundown:

    1. Event.onReady delegates to the new dom:loaded event: Except that as before if functions are added after the DOM is loaded they fire immediately.
    2. DOMBuilder now delegates to Prototype’s new Element: Now difference in usage here though, just less code.
    3. Low Pro’s DOM methods are now gone: Prototype core does everything you should need now.
    4. Behavior.create() works just like the new Class.create(): Yes, you can now create behavior classes that inherit from other behaviors (or indeed any other class). See the Prototype’s site for more information.
    5. New core behaviors: 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.
    6. Event.addBehavior.reassignAfterAjax is now false by default: 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();

    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 the Google Group.

    Grab the new version and have a play.




    @media Ajax

    2007-11-22T10:23:05Z

    Well, that turned out rather nicely I must say. Really high quality presentations and great attendees – I really hope that Patrick makes it happen again. Here are the slides from my presentation: Metaprogramming JavaScript.

    (object) (embed)

    In other news, Low Pro 0.5 is nearly ready to rock. The new version is quite a lot smaller as Prototype 1.6 has solved so many of the things I used to fix with Low Pro. It does however have a few nice new features. Watch this space.




    Custom Attributes And Class Names

    2007-12-21T23:41:28Z

    At the Rich Web Experience, Alex Russell did a presentation entitled Standards Heresy, 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 Aaron Gustafson’s response and is a really interesting discussion. However, I’m not going to comment on the politics of the W3C 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:
    ...
    At the Rich Web Experience, Alex Russell did a presentation entitled Standards Heresy, 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 Aaron Gustafson’s response and is a really interesting discussion. However, I’m not going to comment on the politics of the W3C 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:
    ...
    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 HTML. While the W3C/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 HTML is critically important. Having a
    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. Although HTML 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
    . 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. So we want our semantic HTML and to keep our behaviour data out of our document. Take a leaf out of CSS’s book. We c[...]