If you don't listen to music alot on your computer but have an iPod and would like to keep track... well, here you go.
read more | digg story
Saturday, April 01, 2006
Last.FM your iPod.
If you don't listen to music alot on your computer but have an iPod and would like to keep track... well, here you go.
read more | digg story
read more | digg story
Last.FM your iPod.
If you don't listen to music alot on your computer but have an iPod and would like to keep track... well, here you go.
read more | digg story
read more | digg story
Monday, March 27, 2006
Beatles taking Apple to court over theft of trademark
It is the ultimate battle of the generations.
This week the Apple Corps goes to the High Court seeking multimillion-pound damages against Apple Computer, the creators of the iPod, over their hugely successful iTunes Music Store.
In one corner Sir Paul McCartney and Ringo Starr, the ultimate stars of vinyl who defined music in the 1960s. In the other, the creators of a small white box that has revolutionised the way we buy and listen to music.
Apple Corps, owned by the former Beatles and their heirs, still owns the licensing rights to Beatles’ products. It is claiming that the introduction of iTunes broke a $26 million settlement under which Apple Computer agreed to steer clear of the music business, for which the Beatles’ company retains the famous trademark. It is the latest clash in one of Britain’s longest-running corporate legal battles.
Any damages for this latest clash could amount to tens of millions of pounds because it concerns Apple Computer’s hugely successful iTunes Music Store and iPod digital music players.
The court will be treated to a demonstation of an iPod, but it is unlikely to play a Beatles song, as they have not been licensed for download and it would therefore be illegal.
The Beatles first used a logo of a Granny Smith in 1968 when they founded the Apple Corps to distribute their records and those of other artists they signed to the Apple record label. The records had a ripe apple on one side and a neatly sliced half on the reverse.
The Apple Records subsidiary is still active as the licensing agent for Beatles products.
Steve Jobs, chief executive of Apple Computer, founded his company in 1976 with a logo of a rainbow-coloured apple with a bite taken out of it. Apple Corps sued him five years later, accepting an $80,000 settlement and a promise that the computer company would stay out of the music business.
The companies clashed again in 1989 after Apple Computer introduced a music-making program. The computer company settled in 1991, for $26 million. Apple Corps was awarded rights to the name on “creative works whose principal content is music” while Apple Computer was allowed “goods and services . . . used to reproduce, run, play or otherwise deliver such content”.
Critically, however, the agreement prevented Apple Computer from distributing content on physical media. This was designed to cover CDs and tapes, but it is unclear whether it included later inventions such as digital music files or devices used to play them.
Apple Computer will argue that its music service, which has sold more than a billion songs since 2002, is merely data transmission.
The case is scheduled to begin on Wednesday at the High Court before Mr Justice Mann, a self-professed fan of music and computers. He is no stranger to the iPod, having inquired of both sides some time ago if he should disqualify himself from hearing the case because he owned one.
The owners of Apple Corps — Sir Paul, Ringo Starr, Yoko Ono and Olivia Harrison — will not attend the hearing, but witnesses will include Neil Aspinall, the company’s managing director and the former Beatles road manager; and Eddy Cue, head of internet services at Apple Computer.
read more | digg story
This week the Apple Corps goes to the High Court seeking multimillion-pound damages against Apple Computer, the creators of the iPod, over their hugely successful iTunes Music Store.
In one corner Sir Paul McCartney and Ringo Starr, the ultimate stars of vinyl who defined music in the 1960s. In the other, the creators of a small white box that has revolutionised the way we buy and listen to music.
Apple Corps, owned by the former Beatles and their heirs, still owns the licensing rights to Beatles’ products. It is claiming that the introduction of iTunes broke a $26 million settlement under which Apple Computer agreed to steer clear of the music business, for which the Beatles’ company retains the famous trademark. It is the latest clash in one of Britain’s longest-running corporate legal battles.
Any damages for this latest clash could amount to tens of millions of pounds because it concerns Apple Computer’s hugely successful iTunes Music Store and iPod digital music players.
The court will be treated to a demonstation of an iPod, but it is unlikely to play a Beatles song, as they have not been licensed for download and it would therefore be illegal.
The Beatles first used a logo of a Granny Smith in 1968 when they founded the Apple Corps to distribute their records and those of other artists they signed to the Apple record label. The records had a ripe apple on one side and a neatly sliced half on the reverse.
The Apple Records subsidiary is still active as the licensing agent for Beatles products.
Steve Jobs, chief executive of Apple Computer, founded his company in 1976 with a logo of a rainbow-coloured apple with a bite taken out of it. Apple Corps sued him five years later, accepting an $80,000 settlement and a promise that the computer company would stay out of the music business.
The companies clashed again in 1989 after Apple Computer introduced a music-making program. The computer company settled in 1991, for $26 million. Apple Corps was awarded rights to the name on “creative works whose principal content is music” while Apple Computer was allowed “goods and services . . . used to reproduce, run, play or otherwise deliver such content”.
Critically, however, the agreement prevented Apple Computer from distributing content on physical media. This was designed to cover CDs and tapes, but it is unclear whether it included later inventions such as digital music files or devices used to play them.
Apple Computer will argue that its music service, which has sold more than a billion songs since 2002, is merely data transmission.
The case is scheduled to begin on Wednesday at the High Court before Mr Justice Mann, a self-professed fan of music and computers. He is no stranger to the iPod, having inquired of both sides some time ago if he should disqualify himself from hearing the case because he owned one.
The owners of Apple Corps — Sir Paul, Ringo Starr, Yoko Ono and Olivia Harrison — will not attend the hearing, but witnesses will include Neil Aspinall, the company’s managing director and the former Beatles road manager; and Eddy Cue, head of internet services at Apple Computer.
read more | digg story
Sunday, March 26, 2006
AJAX Site Design using Prototype 1
By now the entire World has heard about AJAX, even those who don’t care about Web-Development have seen the potential of this new technology. Everybody is tired of endless introductions on how cool AJAX is and those endless lists of good examples like Google Suggest, GMail and alike, so I decided to cut a long story short and jump right into the real tutorial.
Is this tutorial any different from the others? Well yes and no, it is different in being a tutorial on how to design and build a complete site and not just some fancy little details like how to turn caching in AJAX off or how to create a fancy widget. To keep the tutorial readable, and to avoid having to implement low level functionality, I’m using the dojo toolkit, I tried prototype too and really enjoyed working with being a really nice and easy to use Library, but dojo provides much more functionality bundled with it. For both frameworks one thing is true: documentation is scarse, and I spent alot time debugging and reading posts on the newsgroups.
For debugging I suggest using Firefox Venkman and the really nice Firebug extension, which make AJAX a lot easier to understand, especially FireBug’s "Log each Request" Feature.
In this tutorial we will try to design a community portal as it has a wide range of different components that give a good overview of what is archievable with AJAX, also it should provide you with the basic tools that will help you in more complex applications.
What we want
As developers we need to know where we want to go, before starting right away. The requirements analysis is not part of this tutorial so I’ll just write down the basic functionality for our Portal:- Pages: Load and show simple HTML Formatted content.
- User: we want to be a community so the possibility for users to register themselfs, create a Profile and communicate with others is fundamental.
- Messages: some sort of messaging center is nice too, and not too difficult to implement, it allows private communication between the users.
- Forum: talking about communications, what could be better than a Forum to let the Users talk about whatever they want?
The Layout
Although the focus should be on the development of the functionality, the layout is still as important as the application itself. It gets even more important because the application can be good but without an interface that is functional it is useless. We’ll use a layout that is easy yet functional:- The content area.
- A sidebar for context related options.
- The main menu (basically this just selects between modules).
- The title, nothing fancy here
- A list with the online users.
Modules
Basically with AJAx we step away from the classic one page-at-a-time view of doing things, and we have to start talking about a more Event Driven architecture, or MVC-Model if you prefer.We’ll define an API that abstracts from the actual page so that we can then create modules that do more complex tasks.
To get back to this tutorial we will have several small modules that represent parts on the site, along with real modules we will have some virtual modules that take care of some functionality, but more on this later. Modules in this tutorial include:
- Page: this will be the first module we will be implementing, it allows to simply display the contents of a file in the contents area of the site, it does nothing fancy.
- User: this module is used for several different tasks:
- Register: register a new User
- Login
- Profile: show the profile of a User
- Online: once we have users we can easily implement a component that allows us to show which users are online, and with AJAX this is possible almost in realtime. It is a nice effect and very easy to implement.
- Forum: what would a community site be without a Forum?
The implementation
We will encapsulate all of our functionality in JavaScript variables, this is similar to static classes in Java and makes it possible to have some sort of clean namespace division between the modules. First of all we will have to create the engine. The engine is the part that handles loading of all the other modules and gives them abstract ways to interact with the page. The idea behind this is that the page interface (layout, stylesheet, …) and Engine build an abstraction layer so that it is easier to implement the functionality easier, without having to bother about representational issues. In other words we build an API.The first and morst important thing the engine has to do is initialize everything.
var Engine = {
bootstrap: function(){
this.setStatus(“Loading…”);
dojo.require(“dojo.io.*”);
dojo.hostenv.writeIncludes();
if((“”+document.location).indexOf(‘#’) < 0){
Engine.loadPage(“#Page/Welcome”);
}else{
Engine.loadPage(“” + document.location);
}
},
This part is easy to understand it does nothing else than set the status to "Loading…", then include some dojo packages and then display a page using Engine.loadPage() as is shown later on. As you can see everything is bundled into a variable named "Engine" thus making it easy to reference it from outside. The bootstrap function is called by the following code in the page:
<body onload=“Engine.bootstrap()”></body>
The next thing to do is to give the Engine the ability to load modules, this is done by downloading a JavaScript file that contains the Module (again encapsulated in its own namespace) and then calling init() of the Module which will initialize the module:
loadedModules: new Array(),
modules: new Array(),
loadModule: function(module){
if(Engine.loadedModules[module])
return;
dojo.io.bind({
url: “javascript/” + module + “.js”,
sync: true,
error: function(type, evaldObj){Engine.showError(“Error while loading module.”);},
load: function(type, data, evt){
eval(data);
Engine.modules[module].execute(uri);
}
});
},
For performance issues we don’t want to download the modules more than once, that’s why we use the two arrays in the first two lines: loadedModules[] is an array of booleans which to every modulename tells us if it was loaded or is yet to be loaded, the second array contains references to the Modules themselfs (being variables they can be referenced like this). loadModules() itself does nothing fancy, it just issues a Synchronous XMLHTTPRequest to download the Module’s source code. It’s synchronous because we don’t want anything to happen at this stage, a call to a function that is not yet loaded for example, this gives us a certain security. Notice that the code is evaluated using eval().
Now we move on to the real magic: loadPage(). It will get a URI as input and it will then load the correct module and pass control to the module, which will then take care of the rest:
uri: "/",
loadPage: function(url){
Engine.setStatus(“Loading…”);
if(!url)
url = “” + document.location;
var hashIndex = url.indexOf(‘#’);
if(hashIndex < 0 || hashIndex <= url.length-2)
return Engine.hideStatus;
uri = url.substring(hashIndex + 1);
var moduleLength;
if(uri.indexOf(‘/’) > 0)
moduleLength = uri.indexOf(‘/’);
else
moduleLength = uri.length;
var module = uri.substring(0,moduleLength);
uri = uri.substring(uri.indexOf(‘/’));
if(Engine.loadedModules[module] && ! dojo.lang.isUndefined(Engine.modules[module])){
Engine.modules[module].execute(uri);
}else{
Engine.loadModule(module);
}
},
The URI is there so other modules and function get work with it easily without having to parse it over again. As you can see loadPage() mainly interprets the URL. Determining the module to load is fairly easy being the first part of the Query string. Some may ask why we’re using URLs like "http://www.example.com/Page#This/is/a/long/string". This is because we don’t want to break the ability to bookmark the pages. AJAX itself does break the bookmarkability because everythin happens in a single page, whereas without AJAX every URL identified a single resource. We use the part behind the ‘#’ because the browser does not issue another request to the webserver, which would unload the entire AJAX application, yet we assign a resouce to a unique URL. bootstrap() also loads the requested page from the URL using loadPage(). Cutting a long story short: a user can browse through our site then copy&paste the URL somewhere and when he returns to the URL he will see exaclty the page he left.
The URL is interpreted in the following way:
- Everything in front of the ‘#’ is discarded as it is only the location of the application.
- The part between the ‘#’ and the first ‘/’ is the module name which will be loaded if it isn’t yet.
- Everything from the ‘/’ to the end of the URL is the argument that is passed to the Module’s execute() function (see the Page module below as an example).
All that is left now to do is implementing some helper functions that will later be used by the modules:
setStatus: function(message){
if($(’status’) != null){
$(’status’).parentNode.removeChild($(’status’));
}
var body = document.getElementsByTagName(“body”)[0];
var div = document.createElement(“div”);
div.style.position = “absolute”;
div.style.top = “50%”;
div.style.left = “50%”;
div.style.width = “200px”;
div.style.margin = “-12px 0 0 -100px”;
div.style.border = “0px”;
div.style.padding = “20px”;
div.style.opacity = “0.85″;
div.style.backgroundColor = “#353555″;
div.style.border = “1px solid #CFCFFF”;
div.style.color = “#CFCFFF”;
div.style.fontSize = “25px”;
div.style.textAlign = “center”;
div.id = ’status’;
body.appendChild(div);
div.innerHTML = message;
},
hideStatus: function(){
Engine.opacityDown($(’status’));
},
opacityDown: function(theElement){
if(theElement == null)
return;
var opacity = parseFloat(theElement.style.opacity);
if (opacity < 0.08){
theElement.parentNode.removeChild(theElement);
}else{
opacity -= 0.07;
theElement.style.opacity = opacity;
setTimeout(function(){Engine.opacityDown(theElement);}, 50);
}
return true;
},
setContent: function(content){
$(‘content’).innerHTML = content;
},
showError: function(message){
Engine.setStatus(message);
setTimeout(“Engine.hideStatus()”,10000);
}
}
This completes the engine. You can find the full script here.
The first module
Now we’ll move on to implement our first real module. It’s task is to load an external resource (an HTML page in this specific case) asynchronously and then display it in the content area.var Page = {
init: function(){
Engine.modules[“Page”] = Page;
Engine.loadedModules[“Page”] = true;
},
execute: function(uri){
try{
dojo.io.bind({
url: “resources” + uri + “.php”,
sync: false,
error: function(type, evaldObj){
Engine.showError(“Error while loading Content.”);},
load: function(type, data, evt){
Engine.setContent(data);
Engine.hideStatus();
});
}catch(e){
alert(e);
}
}
}
Page.init();
But you can already see that we can create really complex modules too as will be shown in a later part of this tutorial when we’ll create a Forum as a Module.
The source of the Page module can be found here.
Putting it all together
You can take a look at the running version of this application or download the entire source code and analyse it. I hope this tutorial was usefull and helped you understand how to design your application. See you all in the next part discussing an Online display.
read more | digg story
AJAX Site Design using Prototype
The internet is full of tutorials explaining those little tricks about AJAX, how to handle XHRequests and all that low level stuff, but nobody tells you how to design the entire application, nobody gives you the overview on how all these things should work together. What good is knowing all those fragments if the developer is unable to put them together to a real use? We have libraries to abstract from the Browser dependant things like actually doing XMLHTTPRequests, and we should concentrate on higher level design to give our clients (or visitors) good and usefull applications.
This is why in this tutorial I’ll try to give you an idea on how the actual design works. I’ll be heavily relying on my last tutorial for the layout of the final application, but we’ll go much more into detail about the decisions we take. Some parts may be applicable to non-Web-2.0 Web design and some even come in handy when designing completely non-web related applications
User Requirements
This step is as important as the coding itself, if I’d start right with the code without first clarifying where I want to go, I’d be wasting time! So there are three important questions that I have to answer:
1. What? What do I (or my boss) want the application to be, what functionality is a must, what is an optional, what are “nice to have” features?
2. Why? Does what I have found that I want to implement fit into the context or would it fit better if I’d change it a bit?
3. When? Do I have to implement everything right now, or may I add some new features one after another, possibly by releasing it before everything is implemented? But much more important: In what order will I have to implement the functionality?
There is not really a point that is more important than the others, take your time documenting and analysing the problems that you expect and fix some priorities, it will greatly speed up the implementation later.
What & Why
We plan to make a community site so the obvious things for a community is that it has to be attractive, easy to use and most important “feel alive”, nobody really wants to be part of a dead community where some casual visitor posts a new message to the forum every few days. To archieve the live feeling we use some little tricks like the regular updates of the list of users that are currently online. Remember that a community is not made up by two or three moderators posting some news from time to time, and filling the Forum with Junk messages nobody cares about.
When
It is important to understand that we’re not delivering a half finished product, it is fully functional, we plan to add more features in a second (and maybe third) step
1. Release
1. Main engine: the basic framework which will allow us to load and execute single modules at a later time.
2. Display some static content.
3. News System
4. User Registration and simple profiles.
2. Release
1. Advanced profiles
2. Private messaging
3. more to come…
This list is off course fairly superficial and does not cover the details of the implementation, it is an abstract planning step, that helps us get a general overview
Under the hood
As mentioned before we don’t want to reinvent the wheel for the millionth time again so we’ll use some libraries:
1. Prototype: probably the most flexible and intuitive AJAX Library on the internet, really lightweight and easy to use.
2. Behaviour: helps us to keep our pages downgradable for browser without JavaScript support (important also for indexing by search engine).
3. script.aculo.us: what would a Web-2.0 application be without nice effects?
This is what we’ll use for the client side. For the server side we’ll use PHP which is nice enough for our purpose, and is a reasonable tradeoff between control, speed and abstractness. For client-server communication we’ll use JSON which allows us to directly encapsulate the data into a JavaScript object, thus making the interpretation of the data much easier, in this tutorial we’ll use the JSON-PHP Library.
The Behaviour Library allows us to bind functionality right to the DOM-Elements without having to add onclick, onload, on[whatever] handlers right in the HTML, it allows us to define some CSS Classes, associate them with certain actions and then the library will take care of the rest for us, fully automagically.
Another main problem with AJAX pages are the “one-page-application” (applications that run entirely on one page) that have some problems with Bookmarking and the famous back button, I decided that the community page will be implemented as a one page application because it makes the whole process much easier, everything runs in one context and we don’t have to care aabout the rest. But we also want to make our pages bookmarkable so we use the hash ending of the URL to identify which page we are currently on.
Basic setup
Ok, so it’s time for us to gather all our libraries and put them into our Project Folder. Our project directory structure looks like this:
The Javascript folder will contain our three libraries (prototype, behaviour and script.aculo.us), the lib directory will contain all our PHP libraries (just the JSON-PHP for now) and static will contain our non dynamic content, such as some welcome textes and help pages.
Implementation
Now we’ll finally getting to see the actual code, it is important that we go one step after another, starting from the basic page layout and then building the functionality on top of that, it will keep us motivated throughout the process to implement a little thing and then test it to see if it works as we’d expected. The base Page is just a Page with the basic content, possibly a welcome message that tells where the user landed and what this is all about. We’ll use a pretty standard Layout for our application, the only requirement for AJAX is that we assign some ID’s to the main parts so that we can easily reference them later. Now we can insert links as we would normally have done, browsers without JavaScript will see a classic page that is completely served by our PHP-Scripts on the server side. For example the first thing we’ll do is display some static, non generated content, like the Welcome page normal links would look like this:
About
The PHP page would take the query string Page/About and would then serve the new page. Now we want to add the AJAX Magic, and this is magic indeed: we’ll use behaviour to catch the request before it is being sent and use AJAX methods from there on to download only the updated regions of the page. First we have to add a Class to all our internal links:
About
this allows us to distinguish the links we want to catch from the links to outside resources, for which AJAX is not applicable anyway.
var rules = {
‘a.link’ : function(el){
// We don’t want to have garbled links…
if(el.onclick)
return;
Engine.log(“Applying rule to “ + el.toString());
var target = el.href.substring(el.href.indexOf(‘?’) + 1);
el.href = “#”+target;
el.onclick = function(event){
var targ;
if (!event) var event = window.event;
if (event.target) targ = event.target;
else if (event.srcElement) targ = event.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;
Engine.log(“Clicked on internal Link “ + targ.toString());
Engine.loadPage(targ.href);
return false;
}
}
};
Behaviour.register(rules);
By doing this we have defined how the user interacts with the AJAX Engine, every element that fires up a certain event will have a class, and behaviour will then take care of the hooking up. Off course the loadPage example isn’t a really complex one but it’s the most common interaction on our page, and it shows the important parts.
See what’s going on
To test and see if all is going as we designed it we will have some way to get feedback from what we do on our Page. Using the alert() function is trivial, too trivial for us and it is really annoying too. Better would be some sort of textfield where our debugging messages are displayed without disturbing the site interaction (alert() opens a popup and focuses it…). We’ll use a popup that can be closed without interupting the application and it won’t try to get the focus for every message.
debug: true,
console: null,
log: function(message){
if(!Engine.debug)
return;
if(!Engine.console){
// Log window does not exist, try to open it.
consoleWnd = window.open(‘’,‘Debug Information’,‘width=350,height=250,menubar=0,toolbar=1,status=0,scrollbars=1,resizable=1′); consoleWnd.document.writeln(‘Console );
Engine.console = consoleWnd.document.body;
}
Engine.console.innerHTML += (message + "
n");
}
This makes it really easy to print debugging information on the running application: just use Engine.log(”Your message here…”); and Engine will take care of the rest. This is exactly what we need: the debugging information when needed but not always. This way of displaying debugging information is really simple, for more advanced features give Log4JS a try.
Modules design
Most AJAX applications in use right now load everything on startup, images, javascript and content. While this is surely an easy way to do things it’s not the best, because it takes a long time (sometimes too long) for the application to be ready, and much of the stuff that is loaded is never used, or used pretty late during execution. For exactly this reason we’ll divide the application into modules. Modules are independent parts of the application, like in our case these would be:
* Page: a simple module which will be implemented in this part of the tutorial. It will load an HTML file from the server and display it in the content area.
* Gallery: a gallery made of user pictures, the goal would also be to use Flickr as a backend for the pictures (e.g. take a group pool and display it, display pictures of a user, display pictures with a certain tag, …)
* News: simply an extension to the Page module this will allow administrators and moderators to post news. News are passed to the Javascript engine using XML. Its main purpose is to demonstrate how to use XML-Files.
* Messages: A module for sending and receiving private messages.
* Forum: the most complex module we’ll see during this tutorial.
First of all we’ll see how to load modules and register them into a module handler (the Engine) and then we’ll move on to actually design the modules.
Module handling
Basically the Engine does specify an API that the modules then may use to access the various parts of the Page, thus we create an abstraction layer between the actual interface and the application. Besides providing an easy to use interface to the Page, the Engine also takes care of loading and managing modules. First of all we’ll have know which modules have already been loaded and if they are not yet loaded we’ll have to load them upon request:
modules: array(),
registerModule: function(moduleName){
…
},
loadModule: function(moduleName, callback){
…
}
notice that we may provide a callback function so that will be executed as soon as the module is loaded. This is because we cannot use the following:
loadModule(“myModule”);
modules[“myModule”].execute();
because loadModule contains an asynchronous call which will immediately return. If we’re unlucky (and most likely we are) the second line is executed before the module has been downloaded and registered, thus generating some really nasty errors. The callback allows us to specify some actions that are to be executed when the module has been definitely loaded.
Modules can range from really easy ones, as the Page-Module is, to really complex things such as message boards, news system, live activity logs, to fully fledged Instant messaging application, there is absolutely no limit to the complexity. The only thing that we require is that the modules adhere to a certain format:
var moduleName = {
init: function(){
// Initialize the module
// Register the module Engine:
Engine.registerModule(moduleName);
},
// …
};
moduleName.init();
The last line is used to initialize the module. Since the module code will be eval()’d it must take care of registering itself to the module handler, the Engine.
The Page Module
The Page module is our first module. On execute it will get the static page via XHRequest from the Web server and display it in the content area. Being the simplest module it consists only of one function and one anonymous function, which will take care of loading the content into the content area. Don’t forget to re-apply the Bahaviours to the loaded code otherwise you might get some unexpected results.
So here it goes, without further ado the code of the Page-Module, by now you should be able to understand what it does.
var Page = {
init: function(){
Engine.log(“Page module loaded.”);
Engine.modules[‘Page’] = Page;
},
execute: function(url){
Engine.setStatus(“Loading content…”);
var myAjax = new Ajax.Request(“static” + url + “.html”,{
method: ‘get’,
// parameters: "?nocache=" + new Date(),
onFailure: function(){
Engine.showError(“Could not load content.”);
Engine.log(“Could not load page “ + url);
},
onSuccess: function(req){
Engine.log(“Loaded page “ + url);
Engine.setContent(req.responseText);
Engine.hideStatus();
}
});
}
};
Page.init();
The rest of the Engine
The engine still isn’t done by now, some functions from above are still missing but it is easy to guess what they do, we simply need some helper functions such as setContent, setStatus, showError and alike, so here goes the rest of the code:
setStatus: function(message){
if($(’status’) == null){
var body = document.getElementsByTagName(“body”)[0];
var div = document.createElement(“div”);
div.id = ’status’;
body.appendChild(div);
}
var node = $(’status’);
node.innerHTML = message;
new Effect.Appear(node);
},
hideStatus: function(){
new Effect.Fade($(’status’));
},
showError: function(message){
Engine.setStatus(message);
Engine.setTimeout(“Engine.hideStatus();”,15000);
},
setContent: function(content){
$(‘content’).innerHTML = content;
},
What’s next?
In the next part of this tutorial we will finally add some really new code that hasn’t yet been covered by my first tutorial, namely we will implement a signup form and some simple user management. For now take a look at the working copy of the application here, or download a snapshot of the code here.
Other resources
* Sergio Pereira’s really good introduction to Prototype
* My first AJAX tutorial
* Prototype Dissected: some really nice cheatsheets for prototype.js
Tools
* FireFox Venkman: the javascript debugger of FireFox (does not work with 1.5.0.1, but the guys over at GetAhead got a fix).
* FireBug Extension: FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter.
* Eclipse AJAX Toolkit Framework:AJAX Toolkit Framework (ATF) provides extensible tools for building IDEs for the many different AJAX (asynchronous JavaScript and XML) run-time environments (such as Dojo, Zimbra, etc.). This technology also contains features for developing, debugging, and testing AJAX applications. The framework provides enhanced JavaScript editing features such as edit-time syntax checking; an embedded Mozilla Web browser; an embedded DOM browser; and an embedded JavaScript debugger.
read more | digg story
This is why in this tutorial I’ll try to give you an idea on how the actual design works. I’ll be heavily relying on my last tutorial for the layout of the final application, but we’ll go much more into detail about the decisions we take. Some parts may be applicable to non-Web-2.0 Web design and some even come in handy when designing completely non-web related applications
User Requirements
This step is as important as the coding itself, if I’d start right with the code without first clarifying where I want to go, I’d be wasting time! So there are three important questions that I have to answer:
1. What? What do I (or my boss) want the application to be, what functionality is a must, what is an optional, what are “nice to have” features?
2. Why? Does what I have found that I want to implement fit into the context or would it fit better if I’d change it a bit?
3. When? Do I have to implement everything right now, or may I add some new features one after another, possibly by releasing it before everything is implemented? But much more important: In what order will I have to implement the functionality?
There is not really a point that is more important than the others, take your time documenting and analysing the problems that you expect and fix some priorities, it will greatly speed up the implementation later.
What & Why
We plan to make a community site so the obvious things for a community is that it has to be attractive, easy to use and most important “feel alive”, nobody really wants to be part of a dead community where some casual visitor posts a new message to the forum every few days. To archieve the live feeling we use some little tricks like the regular updates of the list of users that are currently online. Remember that a community is not made up by two or three moderators posting some news from time to time, and filling the Forum with Junk messages nobody cares about.
When
It is important to understand that we’re not delivering a half finished product, it is fully functional, we plan to add more features in a second (and maybe third) step
1. Release
1. Main engine: the basic framework which will allow us to load and execute single modules at a later time.
2. Display some static content.
3. News System
4. User Registration and simple profiles.
2. Release
1. Advanced profiles
2. Private messaging
3. more to come…
This list is off course fairly superficial and does not cover the details of the implementation, it is an abstract planning step, that helps us get a general overview
Under the hood
As mentioned before we don’t want to reinvent the wheel for the millionth time again so we’ll use some libraries:
1. Prototype: probably the most flexible and intuitive AJAX Library on the internet, really lightweight and easy to use.
2. Behaviour: helps us to keep our pages downgradable for browser without JavaScript support (important also for indexing by search engine).
3. script.aculo.us: what would a Web-2.0 application be without nice effects?
This is what we’ll use for the client side. For the server side we’ll use PHP which is nice enough for our purpose, and is a reasonable tradeoff between control, speed and abstractness. For client-server communication we’ll use JSON which allows us to directly encapsulate the data into a JavaScript object, thus making the interpretation of the data much easier, in this tutorial we’ll use the JSON-PHP Library.
The Behaviour Library allows us to bind functionality right to the DOM-Elements without having to add onclick, onload, on[whatever] handlers right in the HTML, it allows us to define some CSS Classes, associate them with certain actions and then the library will take care of the rest for us, fully automagically.
Another main problem with AJAX pages are the “one-page-application” (applications that run entirely on one page) that have some problems with Bookmarking and the famous back button, I decided that the community page will be implemented as a one page application because it makes the whole process much easier, everything runs in one context and we don’t have to care aabout the rest. But we also want to make our pages bookmarkable so we use the hash ending of the URL to identify which page we are currently on.
Basic setup
Ok, so it’s time for us to gather all our libraries and put them into our Project Folder. Our project directory structure looks like this:
The Javascript folder will contain our three libraries (prototype, behaviour and script.aculo.us), the lib directory will contain all our PHP libraries (just the JSON-PHP for now) and static will contain our non dynamic content, such as some welcome textes and help pages.
Implementation
Now we’ll finally getting to see the actual code, it is important that we go one step after another, starting from the basic page layout and then building the functionality on top of that, it will keep us motivated throughout the process to implement a little thing and then test it to see if it works as we’d expected. The base Page is just a Page with the basic content, possibly a welcome message that tells where the user landed and what this is all about. We’ll use a pretty standard Layout for our application, the only requirement for AJAX is that we assign some ID’s to the main parts so that we can easily reference them later. Now we can insert links as we would normally have done, browsers without JavaScript will see a classic page that is completely served by our PHP-Scripts on the server side. For example the first thing we’ll do is display some static, non generated content, like the Welcome page normal links would look like this:
About
The PHP page would take the query string Page/About and would then serve the new page. Now we want to add the AJAX Magic, and this is magic indeed: we’ll use behaviour to catch the request before it is being sent and use AJAX methods from there on to download only the updated regions of the page. First we have to add a Class to all our internal links:
About
this allows us to distinguish the links we want to catch from the links to outside resources, for which AJAX is not applicable anyway.
var rules = {
‘a.link’ : function(el){
// We don’t want to have garbled links…
if(el.onclick)
return;
Engine.log(“Applying rule to “ + el.toString());
var target = el.href.substring(el.href.indexOf(‘?’) + 1);
el.href = “#”+target;
el.onclick = function(event){
var targ;
if (!event) var event = window.event;
if (event.target) targ = event.target;
else if (event.srcElement) targ = event.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;
Engine.log(“Clicked on internal Link “ + targ.toString());
Engine.loadPage(targ.href);
return false;
}
}
};
Behaviour.register(rules);
By doing this we have defined how the user interacts with the AJAX Engine, every element that fires up a certain event will have a class, and behaviour will then take care of the hooking up. Off course the loadPage example isn’t a really complex one but it’s the most common interaction on our page, and it shows the important parts.
See what’s going on
To test and see if all is going as we designed it we will have some way to get feedback from what we do on our Page. Using the alert() function is trivial, too trivial for us and it is really annoying too. Better would be some sort of textfield where our debugging messages are displayed without disturbing the site interaction (alert() opens a popup and focuses it…). We’ll use a popup that can be closed without interupting the application and it won’t try to get the focus for every message.
debug: true,
console: null,
log: function(message){
if(!Engine.debug)
return;
if(!Engine.console){
// Log window does not exist, try to open it.
consoleWnd = window.open(‘’,‘Debug Information’,‘width=350,height=250,menubar=0,toolbar=1,status=0,scrollbars=1,resizable=1′); consoleWnd.document.writeln(‘
Engine.console = consoleWnd.document.body;
}
Engine.console.innerHTML += (message + "
n");
}
This makes it really easy to print debugging information on the running application: just use Engine.log(”Your message here…”); and Engine will take care of the rest. This is exactly what we need: the debugging information when needed but not always. This way of displaying debugging information is really simple, for more advanced features give Log4JS a try.
Modules design
Most AJAX applications in use right now load everything on startup, images, javascript and content. While this is surely an easy way to do things it’s not the best, because it takes a long time (sometimes too long) for the application to be ready, and much of the stuff that is loaded is never used, or used pretty late during execution. For exactly this reason we’ll divide the application into modules. Modules are independent parts of the application, like in our case these would be:
* Page: a simple module which will be implemented in this part of the tutorial. It will load an HTML file from the server and display it in the content area.
* Gallery: a gallery made of user pictures, the goal would also be to use Flickr as a backend for the pictures (e.g. take a group pool and display it, display pictures of a user, display pictures with a certain tag, …)
* News: simply an extension to the Page module this will allow administrators and moderators to post news. News are passed to the Javascript engine using XML. Its main purpose is to demonstrate how to use XML-Files.
* Messages: A module for sending and receiving private messages.
* Forum: the most complex module we’ll see during this tutorial.
First of all we’ll see how to load modules and register them into a module handler (the Engine) and then we’ll move on to actually design the modules.
Module handling
Basically the Engine does specify an API that the modules then may use to access the various parts of the Page, thus we create an abstraction layer between the actual interface and the application. Besides providing an easy to use interface to the Page, the Engine also takes care of loading and managing modules. First of all we’ll have know which modules have already been loaded and if they are not yet loaded we’ll have to load them upon request:
modules: array(),
registerModule: function(moduleName){
…
},
loadModule: function(moduleName, callback){
…
}
notice that we may provide a callback function so that will be executed as soon as the module is loaded. This is because we cannot use the following:
loadModule(“myModule”);
modules[“myModule”].execute();
because loadModule contains an asynchronous call which will immediately return. If we’re unlucky (and most likely we are) the second line is executed before the module has been downloaded and registered, thus generating some really nasty errors. The callback allows us to specify some actions that are to be executed when the module has been definitely loaded.
Modules can range from really easy ones, as the Page-Module is, to really complex things such as message boards, news system, live activity logs, to fully fledged Instant messaging application, there is absolutely no limit to the complexity. The only thing that we require is that the modules adhere to a certain format:
var moduleName = {
init: function(){
// Initialize the module
// Register the module Engine:
Engine.registerModule(moduleName);
},
// …
};
moduleName.init();
The last line is used to initialize the module. Since the module code will be eval()’d it must take care of registering itself to the module handler, the Engine.
The Page Module
The Page module is our first module. On execute it will get the static page via XHRequest from the Web server and display it in the content area. Being the simplest module it consists only of one function and one anonymous function, which will take care of loading the content into the content area. Don’t forget to re-apply the Bahaviours to the loaded code otherwise you might get some unexpected results.
So here it goes, without further ado the code of the Page-Module, by now you should be able to understand what it does.
var Page = {
init: function(){
Engine.log(“Page module loaded.”);
Engine.modules[‘Page’] = Page;
},
execute: function(url){
Engine.setStatus(“Loading content…”);
var myAjax = new Ajax.Request(“static” + url + “.html”,{
method: ‘get’,
// parameters: "?nocache=" + new Date(),
onFailure: function(){
Engine.showError(“Could not load content.”);
Engine.log(“Could not load page “ + url);
},
onSuccess: function(req){
Engine.log(“Loaded page “ + url);
Engine.setContent(req.responseText);
Engine.hideStatus();
}
});
}
};
Page.init();
The rest of the Engine
The engine still isn’t done by now, some functions from above are still missing but it is easy to guess what they do, we simply need some helper functions such as setContent, setStatus, showError and alike, so here goes the rest of the code:
setStatus: function(message){
if($(’status’) == null){
var body = document.getElementsByTagName(“body”)[0];
var div = document.createElement(“div”);
div.id = ’status’;
body.appendChild(div);
}
var node = $(’status’);
node.innerHTML = message;
new Effect.Appear(node);
},
hideStatus: function(){
new Effect.Fade($(’status’));
},
showError: function(message){
Engine.setStatus(message);
Engine.setTimeout(“Engine.hideStatus();”,15000);
},
setContent: function(content){
$(‘content’).innerHTML = content;
},
What’s next?
In the next part of this tutorial we will finally add some really new code that hasn’t yet been covered by my first tutorial, namely we will implement a signup form and some simple user management. For now take a look at the working copy of the application here, or download a snapshot of the code here.
Other resources
* Sergio Pereira’s really good introduction to Prototype
* My first AJAX tutorial
* Prototype Dissected: some really nice cheatsheets for prototype.js
Tools
* FireFox Venkman: the javascript debugger of FireFox (does not work with 1.5.0.1, but the guys over at GetAhead got a fix).
* FireBug Extension: FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter.
* Eclipse AJAX Toolkit Framework:AJAX Toolkit Framework (ATF) provides extensible tools for building IDEs for the many different AJAX (asynchronous JavaScript and XML) run-time environments (such as Dojo, Zimbra, etc.). This technology also contains features for developing, debugging, and testing AJAX applications. The framework provides enhanced JavaScript editing features such as edit-time syntax checking; an embedded Mozilla Web browser; an embedded DOM browser; and an embedded JavaScript debugger.
read more | digg story
Subscribe to:
Posts (Atom)