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.
Archive
Latest Comments
- zxdvcs Commented on Reading Arabic in a PuTTY Connection
- zxdvcs Commented on Reading Arabic in a PuTTY Connection
- Ed Hardy Commented on Check Out Our iGoogle Gadgets
- Ed Hardy Commented on Thin, the thin server that can!
