eSpace

I bet many of you have already seen the iPhone SDK presentation. I believe that many will be tempted by the platform. There are barriers for entry though. You have to do all development on a Mac, you have to have an iPhone (emulators are not for production testing), you have to be a partner in the Apple developer program and you have to write code in Objective-C.

In a previous article, we saw how DOM manipulation can become so handy using JavaScript Templates. Massive changes could be applied to the HTML document hierarchy using one-line JavaScript functions. In this article I will introduce a generic web development technique that we can name Client-side Views. We will build on our knowledge of JST in order to compose a closed set of tools to follow client-side views with minimal effort. At the end we will get to know the benefits obtained by following such a technique.

When developing a website that collects visitors’ data, it is important to specify a privacy policy so that site visitors know what kind of data is collected and who will access this data. So, if a user doesn’t want to share his phone number or even his employer name, he can instruct his browser to warn him. I didn’t find this feature in current browsers, though I found an addon to IE (http://www.PrivacyBird.org) that warns users of the site’s data collection policy.

JavaScript has been going through a step by step evolution for a while now. Many people are unaware that new JavaScript features are being added to almost every new FireFox major release. And while most references are still quoting the 1.5 release, 1.6, 1.7 and even 1.8 are out now and can be used today.

An undisputed fact is that JavaScript acts as a cornerstone to Web 2.0 application development. Web 2.0 applications extensively rely on JavaScript logic to manipulate DOM elements on the fly. Let’s consider a typical example.

I have been working on a Facebook application using their all-new JavaScript client library. I was trying to reuse a large self-contained module that relied heavily on prototype & scriptaculous JS libraries. The module was working just fine outside the context of the Facebook application. But after including the Facebook JS library, runtime JS errors began to appear, especially when initiating a scriptaculous effect. Obviously, that was concluded as to be a compatibility issue between the prototype & scriptacuolous family on one side, and the Facebook JS client library on the other.

Building a large-scale web application can be troublesome. It leaves us facing all sorts of optimization problems. A very good – but not easy - solution is to use caching. Caching is a real lifesaver as it can help with minimizing i) database queries and ii) string operations.

These are the two main problems that can affect the performance of a web application.

An essential feature of all respectable web frameworks is a reliable user authentication mechanism. Nevertheless, one might be tempted to write his own from scratch, and the reasons are many. It could be that you don’t like the way your favorite framework does the task, or you might feel a need to tweak it a little bit. Maybe you’re too paranoid to let a third party handle it for you! You might not be using a framework in the first place, or you might even be writing your own!

In this post, I’m going to discuss a simple mechanism that has served us well in several projects. It’s straightforward and flexible enough to be used in almost any project, but just like any solution to a software problem, there’s no such thing as a silver bullet; you have to choose the right tool. So, before we go any further, let’s first state precisely what we’re looking for in our sought solution.