Christian Heilmann

Author Archive

The seven rules of unobtrusive JavaScript

Monday, November 12th, 2007

I’ve written a lot about unobtrusive JavaScript before, but I never really held a workshop about it. Well, now as part of the Paris Web Conference later this week in Paris, France I am giving one which is already sold out and I am very much looking forward to it.

As part of the workshop I prepared my materials and wanted to have a nice outline to follow. I took this as an opportunity to build up on the older materials and the outcome of this exercise is that I managed to define the rules of unobtrusive JavaScript, which are:

  • Do not make any assumptions
  • Find your hooks and relationships
  • Leave traversing to the experts
  • Understand browsers and users
  • Understand Events
  • Play well with others
  • Work for the next developer

I’ve explained them all in some detail here: The seven rules of unobtrusive JavaScript

After the workshop I will also add the code demos with some more detail, but that’ll be most probably after @media Ajax.

I hope this is helpful to you, it is creative commons, so use it for good.

[tags]javascript,unobtrusive,unobtrusivejavascript,methodology,planning,webdevtrick,scripting,bestpractices[/tags]

Another Hack Day – this time in Brighton and on a farm!

Thursday, November 8th, 2007

I’ll still be in Paris, but were I here I’d be very interested to go. Sussex Folk who want to spend a Saturday developing some prototypes and bounce ideas of other developers can come to Brighton on the 17th of November to attend the Farm Hack Day.

From the horse’s (cow’s, chicken’s…) mouth:

Hack Day is a chance for web developers and designers to get together and work on small, fun projects, e.g. a new widget for their website. During the day people will learn from each other and show off their skills in a friendly, slightly geeky environment. This Hack Day is organised by members of the Brighton Farm freelancers group. The day will be free, supported by sponsors. Tickets will be allocated through EventWax. [...]. This is part of the Brighton Digital Festival

Darn, I should move to Brighton. Hack on!

[tags]farmhackday,brighton,unconference,sussex,brighton farm[/tags]

wp-super-cache cached too far for me (and others)

Thursday, November 8th, 2007

Having just upgraded this wordpress to the new one I wanted to have the whole goodness and installed wp-cache to have static pages of my posts. However it seems that the newly released wp-super-cache plugin for WordPress had some nasty vulnerabilities.

The first to report that to me was Chris Messina on twitter followed by Stefanie Sullivan reporting about Tiffany Brown having the same issues. Checking the folders created I found the same two injection attempts Tiffany mentioned. The caching allowed code injected as txt urls via “i” or “s” parameters to be executed.

In my case I found that half my server was mirrored into the supercache folder in the plugin’s cache folder. Not good.

I was happy to see that my etc folder and other more interesting bits were not reached yet before I deactivated the plugin. Right now I am playing grepmaster to see if there are some injections left. My action: deactived and deleted all caching plugins and their cache folders (best via SSH as FTP is a PITA with so many files).

[tags]wordpress,wp-super-cache,vulnerability,xss,damn,aaarghhh[/tags]

Dear API Developers, this is what I would like to have

Wednesday, November 7th, 2007

Jonathan Boutelle of Slideshare reacted to my slideshare show widget and liked how I hacked around the API by re-using the RSS feed. He now asked in the comments what I’d like to see from an API. Well, here goes:

  1. Allow for “hackable” URLs, with definition of the output. Flickr and Del.icio.us are good examples, especially the del.icio.us option of defining a callback for the JSON: http://del.icio.us/feeds/json/codepo8 gets me a JSON data wrapped in a Delicious object, http://del.icio.us/feeds/json/codepo8?raw gets me the raw JSON data and http://del.icio.us/feeds/json/codepo8?raw&callback=foo wraps it in a function call to foo(). This rocks! The same goes for defining the output as the last parameter. Flickr does that well – http://api.flickr.com/...format=json for JSON, http://api.flickr.com/...format=rss for RSS, http://api.flickr.com/...format=lol for LOLCAT
  2. make sure that the JSON output is easy to use and does not have any annoying bits (encoded HTML or namespaced attributes – the description property in the flickr JSON to me is pointless weight for example)
  3. make the URL as logical as possible, I don’t like to have to use the user ID in flickr for example when the readable user name would be easier to do.
  4. it’d be great if you could send a unique ID as a parameter as that would allow you to match returned data to calls (as both dynamically created script nodes and Ajax calls may return in any order)

However, all of this does not replace the real API, which should

  1. allow me to define only the data bits that I need (and cut down to the smallest possible feed – no twitter, 150kb JSON is not good!)
  2. give me extras when I go through a developer ID. How about offering me free stats (even as an own API) when I build a widget that uses my ID - we do this now to throttle usage anyways. In a second phase this could also be used for a revenue sharing program.
  3. offer things like enforced authentication (you know the photos you don’t want to show your mother)
  4. allow for local caching methods (deliver the data gzipped for example)
  5. allow me access to things that the open REST calls don’t (my sets, my favourites, my contacts, my profile settings)
  6. be read and write – I want to build widgets that allow data entry from my blog to your systems, without leaving it.

Anything else?

[tags]API,wishlist,REST,JSON,slideshare[/tags]

Sending objects as parameters – good or bad?

Wednesday, November 7th, 2007

One of the differences I keep seeing in functions and methods lately is that people seem to go away from the strict pattern of expecting parameters in a certain form. If you look back some years you might remember functions like the following:


function doLayerFloat(id,start,end,direction,speed,fade,whatelse,Iforgot){
...
}

This, at least to me is rather annoying as I am terrible at remembering the order the parameters need to be sent in (conditioning in PHP confusion probably). The other issue I kept seeing with this was that if you didn’t want to provide some of the parameters but one of the last ones you had to send empty strings or even null values:


doLayerFloat('myDIV',0,30,null,null,true,null,null){
...
}
// or
doLayerFloat('myDIV',0,30,'','','','',''){
...
}

This is both confusing and convoluted. Other scripts I have seen work around the issue by using the arguments array, which at least allows a flexible amount of arguments to be sent.


function doLayerFloat(id){
var args = arguments;
for(var i = 1; i < args.length; i++) {
...
}
}

However, my favourite these days is functions that actually take a few defined parameters (or a single one), allow for it to be several things and allow you to send an object as the properties:


function doLayerFloat(id, props){
var elm = typeof id !== 'string' ? id : document.getElementById(id);
for (var i in props){
...
}
}

This allows the id to be either an element reference or a string and takes an object as the second parameter in which I can define the order and amount any which way I like (provided the method then tests for each of them and their correct values):


doLayerFloat('x',{start:20,end:30,fade:true});
// or
doLayerFloat(myElm,{fade:true,direction:'right'});

This also allows you to define default values should the properties not be set, something you can do in PHP but not in JavaScript. In PHP, this works:


function foo($bar=2,$baz='foo'){
}

In JavaScript that can’t be done, but if you use an object you can predefine if the properties are not set:


function doLayerFloat(id, props){
var elm = typeof id !== 'string' ? id : document.getElementById(id);
props = props || {};
props.start = props.start || 100;
props.fade = props.fade || false;
}

Do you agree? Or is the object literal syntax still too tricky?

[tags]javascript,syntax,parameters,object literal,objectliteral,arguments,codestyle,webdevtrick[/tags]