Archive for the ‘frameworks’ Category

Speaking about the web of data

Wednesday, February 25th, 2009

Today at 19:00 CET I’ll be speaking at a local web meet-up about the web of data. There’ll be a live feed of the talk available and since I’ll be speaking in English you can tune it. This is a quick translation of the abstract posted on Slovenian sites:

Numerous services are emerging on the web that provide data in a computer friendly form through APIs, microformats, feeds,… Even your blog is actually a database as it syndicates its content via feeds and new posts trigger a ping you can subscribe to.

This fact opens new ways of collaboration – so called mash-ups, but this isn’t really a new concept. What’s new about it is the fact that we don’t use this word anymore as all the new services are some sort of a mash-up leveraging existing services. But accessing data is not the only way to leveraging these services – it’s becoming increasingly easy to create an application that lives in other applications without their approval through browser extensions and bookmarklets.

Marko Mrdjenovič from Zemanta will talk about what you can do to make your site more mash-up friendly and why that’s becoming increasingly important. As a developer I’ll also present what options you have and give a few tips on what to do and what to avoid when developing these kind of apps.

If you have any questions during the talk use twitter to tell me and I’ll try to answer them. Or put them in the comments.

Update: The video is now online. It’s in English so go watch it and tell me what you think.

Reblog this post [with Zemanta]


Thursday, February 19th, 2009

There’s a really small probability that someone might need something like this but I did and I’d like to share it.

At Zemanta we have a few different ways of loading our scripts and we cannot always control when they do. The Firefox extension will load the scripts on DOM ready, WordPress plugin will load them somewhere in the middle of the HTML, Drupal and MovableType plugins will load them in the head and IE extension will load them sometime while loading the page.

This all means that we have to delay some of our code execution to when DOM is ready and scripts are loaded. Which is where the problem kicks in.

jQuery has this nice way of doing this with $(document).ready(fn) or short $(fn) which waits until the document is ready and executes the passed fn function. If the document is ready it will execute the function immediately. Our issue lies in what “document is ready” means to jQuery – it means different thing in different browsers.

In browsers that support DOMContentLoaded (Firefox, Webkit, Opera – let’s call them modern browsers) “document is ready” means that either DOMContentLoaded event fired on the document or the load event fired on its window. On IE “document is ready” means that either onreadystatechange fired with readyState === 'complete' on the document or document.documentElement.doScroll("left") is successful (Diego Perini hack). To make this short – if you load jQuery after all the events fired in modern browsers jQuery will never know that the document is ready.

To get around this (we really don’t like having our own hacked version of jQuery) I wrote this little plugin:

(function ($) {
$.readyOrDone = function (fn) {
	var s = document.readyState;
	if (s === 'complete') {

As you can see this will check if document is in a “complete” state and fire the ready method on jQuery which usually fires when DOM is ready – if it fired before it will do nothing. It will then add the function to the ready queue which also has this nice feature of firing immediately if DOM is ready.

All you have to do is change your $(fn) calls to $.readyOrDone(fn) and you have a bulletproof solution for executing functions when DOM is ready even if jQuery was late to the party and has no idea if the document is really ready.

Update: Filed a bug and hoping for the best.

Update 2: I found out that not all browsers provide the readyState property – Firefox on Ubuntu for example. Devised a new version that tries to smartly handle such cases:

(function ($) {
	var time = setTimeout(function () {}, 0),
		lastelm = null;
	$.readyOrDone = function (fn) {
		var s = document.readyState, getLast = function () {
			var elms = document.getElementsByTagName('*');
			return elms[elms.length - 1];
		if (s === 'complete') {
		} else if (typeof s === 'undefined') {
			lastelm = getLast();
			time = setTimeout(function () {
				if (getLast() === lastelm && typeof document.readyState === 'undefined') {
			}, 1000);
Reblog this post [with Zemanta]

Using jQuery for event handling on Objects

Sunday, January 4th, 2009

I’m working on a few projects with jQuery that need event handling. Since I like the way event handling is done in jQuery, I decided to use it to add event handling to internal objects with jQuery (1.2.6 at the time of writing). This seems very easy:

internalObject = {/* code here */};
eventHandler = $(internalObject);

This means that you could now do

eventHandler.bind('customEvent', function (ev) {
	// this is a reference to internalObject

and of course also

eventHandler.trigger('customEvent', {some: 'data'});

which is great.

But in a part of my code this just wouldn’t work. Unfortunately it was my first try at doing jQuery({/* custom object */}) and since I obviously wasn’t at my best when writing it I was sure this couldn’t be done. So I hacked around it.

A few weeks ago I made me a test case and figured out it works when passed an empty object ({}). So I implemented it everywhere and sure enough a part of the code stopped working. Which made me delve into the code to figure out why – a bit of debugging made me think the bug was somewhere in jQuery and I found out that there is a problem with the makeArray function. When it’s trying to create an Array it will test if the object has a length property. But as the comment in uncompressed code neatly points out //the window, strings and functions also have ‘length’ it checks a few things that allows it to handle these objects differently.

This means that

eventHandler = $({});

will work normally, while

eventHandler = $({length:0});

won’t because eventHandler length will be 0.

My problem was that the object I was passing had a length property. As such it got sucked into the else that processes arrays and other array like objects (like arguments and most probably also NodeLists). This meant that what I got back was nothing since length was initially set at 0.

Important update: Don’t do this:

eventHandler = {};
internalObject = {
	customEvent: function () {
		/* some other handling code */
	/* more code */
eventHandler = $(internalObject);
eventHandler.bind('customEvent', function (ev) {
	// this is a reference to internalObject

You will inadvertently create an indefinite recursion as jQuery will try to trigger the native event and will execute elem[ type ](); where elem will be your object and type your event name. If you need an event that has the same name as a method on the object you can use triggerHandler as it will not trigger the default event.

Frameworks in the future..

Sunday, May 14th, 2006

We recently had two workshops on AJAX and in the second one my co-host presented some JavaScript frameworks and we got into a discussion about when we’ll start using one of them. It seems that it was not a question of if but of when. I should point out that both of us are proficient in JavaScript and are not the primary targets of frameworks.

A few days later Eric posted Flummoxed by frameworks that started a huge debate about it (he also posted a later explanation). Yesterday I was also listening to Dustin’s episode 12: YUI Library Discussion about the Yahoo! User Interface Library.

What I got from all this was a weird feeling about frameworks. I can’t decide whether I like them or not and why. I don’t especially like any single one of them. Like any other advanced developer I have my own bunch of methods/functions/objects that I regularly use and copy around. This code evolves automatically as I find bugs or need more features. Frameworks on the other hand do this with a plan. Or so it seems. Hopefully the developers behind them are strong enough to fight the feature requests coming from noobs to keep the core frameworks small, simple and above all understandable. Even though some say bandwidth is almost free nowadays.

After a whole day of pondering I think I like the idea but probably not the hype and the implementations that more than anything frustrate me. I’m off to write my own framework.