You searched for: 'native'

Tuesday, August 1st, 2006 Ajax Upgrade

Category: PHP, Usability, a useful tool for locating PHP classes, has upgraded its search. There are a couple of Ajax goodies. Search results appear as a set of tabs – Packages, Reviews, Forum, etc, and the results for each tab are obtained via remote calls. Likewise for result pagination. There’s also a Suggestion/Auto-Completion feature in the search bar – a site like this is probably a good place for Suggestions, to help explore all the library code out there without knowing precise terms to search for.

The idea is to provide a better organization of the search results. It
is an alternative to the traditional search result pages that present
pages from all site sections in mixed in a single listing.

AJAX is used to retrieve the results from different sections when the
users click on the respective section tab.

The search form also provides auto-completion support. It uses AJAX to
query the site server database and retrieve the top ten most searched
keywords that begin with the first letters typed by the user.

The site search also uses an animation Javascript class to add a nice
touch of style using fade effects to the AJAX based page updates of the
search results and progress feedback messages.

The PHP and Javascript components used in the site to implement these
AJAX and DHTML features are available as Open Source as mentioned in
this PHPClasses site blog post.

Read more about the upgrade in Manuel Lemos’s announcement.

Posted by Michael Mahemoff at 8:54 pm

3 rating from 36 votes

Thursday, July 27th, 2006

Prototypify: Running Prototype code with legacy code

Category: JavaScript, Library, Prototype

Aaron Newton, Product Manager at CNET sent us an email about his issues of using Prototype in production at a large company like CNET:

I’ve made a lot of use of Prototype but using it has been a bit of a controversy here at our network. Specifically, the extensions that are inherent in Prototype often create problems for (poorly written) legacy code and advertising javascript that we must include in our environment to make a buck.

Because it’s not reasonable for our technical producers to regress every ad that runs on our site, I hired a good friend (and far more talented programmer) to help me find a solution. He, one Alex Cruikshank, authored a chunk of code (2.25K) for us that I think could be of great use to those out there who avoid Prototype because of the way it alters Arrays and Objects; specifically, those trying to use your library in an environment where they do not control 100% of the javascript included.

The code, all 3K of it, is a wrapper of sorts that removes all the extensions to Array and Object from Prototype. Then, when you want to make use of Prototype, you just apply this wrapper to your code.

We have put the code up for Prototypify along with the documentation.

Prototypify = function() {


Prototypify.prototypified = false;

// store then remove functions from prototypes of native objects
Prototypify.arrayFunctionHolder = new Object()
for (x in Array.prototype)
Prototypify.arrayFunctionHolder[x] = Array.prototype[x];
delete Array.prototype[x];

Prototypify.stringFunctionHolder = new Object()
for (x in String.prototype)
Prototypify.stringFunctionHolder[x] = String.prototype[x];
delete String.prototype[x];

Prototypify.numberFunctionHolder = new Object()
for (x in Number.prototype)
Prototypify.numberFunctionHolder[x] = Number.prototype[x];
delete Number.prototype[x];

Prototypify.proxy = function( f, proxyArguments )
return function()
var needsPrototypes = ! Prototypify.prototypified;
if ( needsPrototypes )
Prototypify.prototypified = true;
for (x in Prototypify.arrayFunctionHolder)
Array.prototype[x] = Prototypify.arrayFunctionHolder[x];
for (x in Prototypify.stringFunctionHolder)
String.prototype[x] = Prototypify.stringFunctionHolder[x];
for (x in Prototypify.numberFunctionHolder)
Number.prototype[x] = Prototypify.numberFunctionHolder[x];

if ( proxyArguments )
for ( var i=0; i < arguments.length; i++ ) if ( typeof arguments[i] == 'function' ) arguments[i] = Prototypify.proxy( arguments[i], proxyArguments ); } var out = f.apply( this, arguments ); if ( needsPrototypes ) { for ( x in Array.prototype ) delete Array.prototype[x]; for ( x in String.prototype ) delete String.prototype[x]; for ( x in Number.prototype ) delete Number.prototype[x]; Prototypify.prototypified = false; } return out } } Prototypify.instrument = function( clazz, proxyArguments ) { for ( prop in clazz.prototype ) { if ( typeof clazz.prototype[prop] == 'function' ) clazz.prototype[ prop ] = Prototypify.proxy( clazz.prototype[ prop ], proxyArguments ); } } Prototypify.instrumentStatic = function( clazz, proxyArguments ) { for ( prop in clazz ) { if ( typeof clazz[prop] == 'function' ) clazz[ prop ] = Prototypify.proxy( clazz[ prop ], proxyArguments ); } } [/javascript]

Copyright (c) 2006 CNET Networks, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.


Posted by Dion Almaer at 2:55 pm

3 rating from 8 votes

Tuesday, July 25th, 2006

Rediscovering Flyweight for Javascript

Category: Editorial, Programming

We posted about memory problems the other day (“the biggest Ajax problem” :-) and while it’s always good practice to clean up, another good practice is to avoid allocating excessive memory in the first place. To that end, I’ve recently been experimenting with the Gang Of Four Flyweight pattern within Javascript.

Flyweight works like this. Instead of creating an object for every entity, we only allocate a “Flyweight” object only for every type of entity. Because these Flyweight objects don’t have internal, object-specific, state, we have to pass a little context each time. It’s a compromise to cut down on memory. Flyweight often rears its head when you have some kind of object pooling (e.g. stateless session EJBs).

The pattern works well with Ajax apps, where the DOM already holds a lot of context, since we’re displaying that for the user. So I just need to pass in an element (or an element ID) as the context, and the Flyweight object will get the actual state of that element by reading its DOM properties.

To use the canonical blog example, we can have two kinds of comments – ManualComments and TrackbackComments. Assuming this is an Alpha blogger who gets 200 ManualComments and 50 TrackbackComments after posting that it’s cloudy outside, we would have a lot of objects to allocate if we did things the naieve way. And, of course, it would get a lot worse with a dynamic app that keeps creating and deleting objects, if there happened to be a memory leak (yes, which should ideally be avoided, but when you have a deadline and one browser or another isn’t playing nice …).

Instead of holding 250 Comment objects, we simply use two objects – a ManualComment object and a TrackbackComment object. Each div representing a manual comment would then have a “comment” property referencing the (singleton) ManualComment object. Alternatively, we might prefer to implement some kind of factory that accepts an element and gives us back either the ManualComment object or the TrackbackComment object. So when the user clicks a “Mark As Spam” button inside the div, we have a means of getting back either a ManualComment or a TrackbackComment, and we can then call comment.markAsSpam() on it.

We might also have a Comment “superclass” to encapsulate common property (relying on prototype chaining supported by Dojo/Prototype/Base/etc libraries). Unlike Java-style Flyweights, we don’t have to declare abstract methods though; JS being dynamic, we can rely on Duck Typing, so it’s possible that our ManualComment and our TrackbackComment will each have their own markAsSpam() method, but Comment (if it exists at all), will have no such thing.

Posted by Michael Mahemoff at 6:05 pm

3.9 rating from 23 votes

Thursday, July 20th, 2006

XMLHttpRequest Case-Sensitive in IE7

Category: IE, XmlHttpRequest

Sleepyhead has posted a quick note about the XMLHttpRequest support in Internet Explorer 7, some bad news – it’s case-sensitive.

The native XMLHttpRequest object in IE7 is case-sensitive. This is no big surprise – however that was not the case with the XMLHttpRequest active-x object in earlier versions of IE. So if you have old code that used uppercase in method/functions that worked with IE6 you have to change it for it to work in IE7. Took me a while to figure out why an old script of mine wasn’t working…

He gives the code example for his fix, noting that “Status” will no longer be the same as “status”.

Posted by Chris Cornutt at 6:59 am

3.6 rating from 37 votes

Tuesday, July 18th, 2006

Krugle Is Hiring

Discover the search engine for you…the developer

Ajax Developer

We need you !

Can you … Deliver?
We need a high-level web application developer. You are someone who knows all about building dynamic user interfaces for web browsers. You will team up with another developer who has the reputation for being one of the best in the world at this work.

Skills needed for Success:
• Everything AJAX: DHTML, CSS, DOM, XML, XSLT, JavaScript (OOP)
• Fully conversant in web programming techniques and web based applications (HTTP, REST, etc)
• Thorough understanding of Web 2.0 technologies and concepts (blogging, feeds, wikis, etc)
• 2+ yrs experience in full fledged AJAX application development (i.e. google maps, gmail, yahoo mail, zimbra, krugle)
• Analytical, thorough, resourceful and very detail-oriented
• Self-motivated, hardworking, flexible with an ability to learn quickly
• Strong communication and documentation skills

• Push the boundaries of what’s possible with our AJAX-based client software
• Dazzle users with a high utility, highly intuitive interface and drive the competition nuts with imaginative and off-the-hook solutions
• Extend our browser-based client into new UI areas, as we create the right environment for programmers to find, learn, and investigate

Desired Background/Skills:
• BS or MS in computer science or related field, or equivalent experience
• Minimum of 2-4 years of commercial development experience
• Formal structured programming education
• Experience with Ajax libraries/frameworks
• Proficiency with Perl, Python, Java, HCI, SQL, Unix
• Rapid development processes
• Open Source interest/experience

We know that you’re out there…for immediate consideration, submit your resume to and we’ll follow-up with you shortly!

Posted by Ben Galbraith at 7:57 pm
Comment here

2.6 rating from 9 votes

Thursday, June 29th, 2006

Kabuki Withdrawn from Apache

Category: Editorial

Andy Clark of Zimbra wrote a letter to the Apache Incubator where he explained why the Kabuki contribution was now withdrawn.

A few of the things we’ve learned:

  1. Most parties in the OpenAjax initiative believe one sweet spot for AJAX toolkits will be for augmenting existing HTML pages. This is a more evolutionary approach that provides a more generic fallback in terms of accessibility, legacy clients, and so on. So a key constituency is the “HTML design center”, and today we believe Dojo to be a better choice for HTML developers than Kabuki.
  2. At least some of the Java UI developers prefer to continue to do their coding work in Java and then map the resulting application to Javascript for deployment. This is the model at the heart of the Google Web Toolkit (GWT), which is directly targetted at the “Java design center”, and is now available under the Apache license.
  3. Kabuki, which targets object-oriented programming in Javascript, retains its sweet spot for developing more revolutionary AJAX applications (“Javascript design center”) that seek to take the full advantage of the browser’s capabilities in native Javascript.
  4. We think that Kabuki is an ideal fit for a certain class of Ajax solutions but not for others. As such, we expect Kabuki to co-exist with Dojo, GWT, and others. We now agree with other members of OpenAjax that a peer relationship between these projects is best. We feel that this approach facilitates sharing and collaboration and is better than an approach where one project has a special relationship with Apache while others do not.

Is this a big deal? We don’t think so. A lot has changed since Zimbra kindly put this out there, and other open projects already exist for users. I think it is a service to NOT have another Ajax framework waving around, especially one that looks like Java in JavaScript? :)

Posted by Dion Almaer at 8:09 am

3.9 rating from 38 votes

Tuesday, May 30th, 2006

Responsible Asynchronous Scripting

Category: Ajax, Editorial

On, there’s a new column that’s been written up by Shaun Inman, one of the brains behind Mint concerning “Responsible Asynchronous Scripting”.

Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies like images and cookies, native support for the XMLHttpRequest (XHR) object in modern browsers has made it easier than ever to make web apps more responsive and more like their desktop counterparts. This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology.

So what’s a well-intentioned web developer to do? Stop and think about the following before dropping that sudsy, lemon-scented bomb on unsuspecting users.

He suggests a few points developers should ponder before even taking the first step to adding Ajax functionality to their applications. This includes using the right tool for the right job (is it content you’re pulling or an action you’re doing?) and how to inform users that the applications is still doing something even when it can’t be seen. Be sure to check out the comments on this one as well – several great points are made.

Posted by Chris Cornutt at 2:39 pm

3.7 rating from 28 votes

Saturday, May 20th, 2006

Google Web Toolkit: The correct level of abstraction?

Category: Editorial, Google

There has been a lot of buzz around Googles new Google Web Toolkit, an Ajax framework that allows Java developers to stay in Java land and ignore JavaScript.

Ironically, a day earlier I was shown XML11 (not a lot of XML) which is a similar toolkit. Both have the ability to take Java code and codegen JavaScript for you, including porting various Java libraries (e.g. some of java.util).

There are problems that I see with these approaches:

  • Debugging: Remember working with C/C++ compilers back in the day? Before we trusted them? I can’t imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has “a[b] = push(c)” in it. Er. Riiiight.
  • JavaScript isn’t evil: I can understand wanting to stay in your own language. Rails does a good job of this with its abstractions such as RJS. However, I am not scared of JavaScript certainly compared to Java. Ironically with Phonos you could write the client side with GWT and the server-side with JavaScript!
  • Holy JS size batman: GWT claims that there isn’t a huge amount of JS generated. When I looked at one of the simple examples and finally found the JS code that gwt.js automatically downloads I found quite a bit of code. All of it total gobble-di-gook of course (a feature). For anything non-trivial you could see this code getting pretty huge.
  • Abstract higher: One of the lessons learned from MDA was to generate on a higher level of abstraction. Writing assembler code to be run in the JavaScript interpreter seems to be the wrong level of abstraction. Instead, codegen on top of a high level library such as Dojo or Prototype. Rails made a good choice in this manner. As a developer you can even look at the code generated and understand it (and hence tweak it and write your own code gens). When you see the low level assembler speak you get scared from ever looking at it. In the future browsers will be able to have strong namespaces and packages allowing us to share version X of library Y. This library could be JIT’d and hence the JavaScript that you send down is small running on a fast immediate runtime.
  • It isn’t JavaScript, it is browser diffs: Developers are not scared of JavaScript per se. The issue that we have is with cross browser inconsistencies. This problem goes away if we put effort into the toolkits (Dojo, Proto, …) and write on top of those layers.
  • What about the cool stuff?: So you have access to Java APIs. Kinda. You can’t use ANY old Java class. XML11 allows you in theory to keep recursively compiling your code, but what if you get to native code? A lot of Java code won’t make sense in the browser context. At the end of the day you feel good as you are in Java code land, but you are crippled. We have seen that libraries such as allow us to do fantastic effects in our browser applications. Try to do those effects in Swing and you will be scared off. There is no one-line Effect.* library that is for sure. If you dismiss JavaScript you ignore all of the great features, components and libraries available.

I see how these toolkits hit a sweet spot for some developers and teams, but I would like to think that only a small group would fit the bill. What do you think?

Posted by Dion Almaer at 8:12 am

3.7 rating from 134 votes

Friday, May 12th, 2006

Ajax Experience Day 3: Panel

Category: Firefox, IE, The Ajax Experience

With key people present from Mozilla and the IE team present, today’s Ajax Experience panel is focused mostly on browser issues. A rare opportunity for Ajax developers to talk directly with the people who define our day-to-day constraints. As I write this, it’s thirty minutes after the panel finished and there’s still a decent crowd in the front talking to the speakers.

  • Alex Russell – Dojo Toolkit
  • Stuart Halloway – Ajax/Java/Rails Consultant
  • Brendan Eich – Firefox Lead
  • Laurel Reitman – Microsoft IE Lead Program Manager
  • Douglas Crockford – Yahoo!, creator of JSON, general JS evangelist

Here are some notes from the panel…

Why no byte code?
Various reasons. Compiler is a hassle. Can send malformed bytecode and make it take a long time. Was experimental in 1995.

SVG Integration in IE7?
Laurel: No, won’t make it, but we’re looking at it.

Ben: What would you like to see?
Brendan: DOM ?standardised. Local storage – offline in first-class, cross-browser, way.
Laurel: SVG and canvas – heard a lot around the conference. Also heard a lot about offline storage, important too. CSS spec. Accessibility space – Mozilla has done some great work there.
Stuart: Would be really cool to have a test suite that verified the browser does what it’s meant to be doing. Some browsers have done better than others in adopting agile/testing practices – formally having those things would help show which browsers are doing well at standards compliance, etc.
Laurel: Not just standards compliance, also what the community’s asking for.
Brendan: Sure, there’s a difference between real-world standards and those written by W3C etc. It’s not going to be downloaded with yout browser, but something we’d like to collaborate on.
Alex: Safe JSON (de)serialisation. Increasing 2-connection limit would make a lot of things possible. Next version of Windows: when a system builder, or someone bundling windows, has to ship the latest version of IE. Also fast DOM queries.
Laurel: Key word – Security. (wrt JSON)
Brendan: On the map for JS 2 – Safe (de)serialisation with JSON.

What have you given up hope on – impractical or will take 10 years?

Alex: If you’ve been coding JS for a long time, (you feel like anything’s possible) :-).
Laurel: Good to be here at the conference, hear what people want.
Brendan: It’s difficult to have security and power. We need better security models, not just a dialog model that says “Do you trust” becausse most users ignore it.

Robustness of applications

Douglas: Run Yahoo! Mail Beta all day in FF, doesn’t fall over. But others fall over quite readily.
Laurel: Hard to answer, depends on the implementation.
Brendan: Have to test long-running scenarios as well.
Laurel: Agrees. We do stress testing, monitoring of bug reports from end-users, etc.
Stuart: AFAIC if you don’t have a test, it doesn’t exist. As developers, we have a responsibility to meet browser manufacturers at least halfway, produce automated tests … Obviously it’s extremely hard to get coverage (if test takes hours to run). We do have tools like Selenium etc that will help us make it more obvious by way of automated tests where the problem lies.
Brendan: We’re using JSUnit, want to look at test strategy. Moz also looks at bug DB etc., please contribute.
Alex: Nice to grep source of Firefox.
Stuart: MS has a ton of v smart people and a long history of watching industry grope towards something and then jump in. Suggests MS will become a huge open-source provider. Other possibility is that they’ll fail.

What about accessibility and which toolkit should you use? (Prefaced with “I have two questions no-one has asked yet” as everyone keeps asking these at this conference)
Douglas: I’d like to see better affordances in the browsers indicating what its acessible attributes are.
Laurel: Great work done by IBM and Mozilla, we’re seriously looking at it.

Legal or corporate battles on continuing to work together more

Laurel: Patents are one of the biggest problems.
Douglas: Time to close the US patent office (Applause).

In the future, much higher expectations about what websites can do – will mom and pop be able to do it?
Laurel: Toolkits helping to deal with X-browser incompats, making it easy to do
powerful things.

FF lots of bug fixing at the same time as new stuff. Innovation in IE?
Laurel: Can safely say it’s not going to be five years before the next big improvement in the browser. Expect to see a lot of good work…

Alexa tracks popularity by page clicks, but that doesn’t happen much with Ajax.

Douglas: We now have a lot of info about what was going on in the page. But don’t have an accounting system for everyone, what needs to happen.
Brendan: (From another question) FF 3 – Q1 2007.

Just-In-time Compiling

Brendan: Looking at advanced optimisation techniques. ?Hard JITting is hard without type info, which isn’t there now but will be there in the future. Garbage collection difficult – everyone has to watch out for, ongoing area of R&D.

Anyone looking for a complete replacement of HTML, JS, etc. Flash?

Alex: Lots of people are trying, I wish them luck.
Brendan: Flash is a plugin, plugins are second class, that won’t change. If Flash were open or open-source, would be merged in ways that would be wonderful, but don’t think it’s going to happen. W3C people trying to standardise in that area – MS for XAML, FF for XUL, etc. Different languages, different runtimes, IP considerations and compatibility constraints.
Laurel: Even with web today, can use notepad/vi and create some compelling things.

Exposing hooks for IE to build any GUI with it?
Laurel: Can already do it, e.g. AOLExplorer.
Brendan: Sure, a lot of hooks in IE. With Gecko, can write your own ?app.

Is anything we, the users of your tools, aren’t doing which you wish we
would take advantage of?

Stuart: Would be great to see people picking toolkits. Taking advantage of JS as a language, prototype-oriented etc.
Brendan: Functional programming is trickling down – it’s a better style for a lot of JS. I’m not up with the latest

IE7: Fix for Select box, overlapping
Laurel: Select control, can now see over it now. And transparent PNGs. Native XHR.
Ben: Issues about dealing with IE7?
Alex: At one point, NS was wearing the crown, now it’s IE6. From the perspective of a scripter, IE7 is not significantly different. In the same way the CSS community made the point that IE6 wasn’t good for CSS, we said the same about IE7 for JS.
Panel comments about talking to vendors, it’s important to give feedback, etc.

Mashup support

Laurel: Biggest challenge is secure cross-domain.
Douglas: Next thing will be third-party widgets running on the same page, the model doesn’t partition these things.
Brendan: Still under research, pushing towards it over the next couple of years. We don’t sandbox enough right now.
Stuart: Even developers don’t understand the security model within the browser, how much authority you give it. Let alone general users.

Combining frameworks
Stuart: Don’t want to end up where everyone using WebWork must use Dojo, everyone using Rails must use Scriptaculous etc. Should be able to pick things on features, mix and match. It’s not actually hard to combine these things together. Would be 10 minutes of work to fit Scriptaculous and Prototype with Dojo packaging, maybe let’s at least agree on using Dojo packaging.

DOM Compatibility

Brendan: DOM isn’t transparent

Toolkits – Seems like could incrementally keep raising the bar, agree on a common subset of syntax, etc.

Alex: Rate of change issue. e.g. DWR’s use of $() (Joe Walker later clarified this at the panel – not DWR’s issue, just the overall problem about ordering of scripts, overriding issues etc). Even if we decide on something, end up with serious versioning issue. If something’s really really important, maybe should standardise on ecmascript or DOM bindings.
Brendan: XHR is being standardised. Took C a long time to get through various API wars etc. Kind of early.
Stuart: Hard to standardise. e.g. Many people haven’t been exposed to functional programming, others have been but don’t like it. So how do you standardise when people don’t agree on the basic matters of programming style?

Competition is good. Ajax benchmarking initiative?
Brendan: Benchmarking is tricky. The browsers always game it (specific benchmark). I’d like to see a developer-driven effort.
Laurel: Need a broad set of examples, things people are really doing.

MS has an incentive not to innovate to much with IE
Laurel: Can’t speak for executives, but my role on the team is to make IE good, etc. I think both can peacefully coexist. BTW We’re hiring. Investments on Windows Live etc show MS is committed to the platform.
Brendan: If I were Adobe, I’d be pretty nervous. (Might expect action too if web apps take off.)

Posted by Michael Mahemoff at 8:34 pm

2 rating from 231 votes

Friday, May 5th, 2006

AJAX and Screenreaders: When Can it Work?

Category: Accessibility, Ajax

One of the largest complaints that people have about Ajax these days is the lack of standards support in the sites developed with it. Since all of the data is dynamic, there’s problems caused with several different types of applications used for “alternative browsing” – such as screen readers. Developers know this and are trying to take steps to improve the situation, but it’s a slow road so far. In this new article on SitePoint, you can check in on one developer’s quest to get a simple Ajax script to be correctly read in a common screen reading application.

We’ve all heard a great deal of buzz about AJAX in the last few months, and with this talk has come a legion of articles, tips, presentations and practical APIs designed to explore the possibilities and try to arrive at best-practice techniques. But, for all of the excitement and hype, still very little has been said on the subject of AJAX and accessibility.

Wherever we look, from discussions at AccessifyForum, to popular blogs like those of Derek Featherstone, and Peter Paul-Koch, the one thing we can all agree on is that we need more information.

And that’s why I’ve written this article: to present some of the data and analysis I’ve compiled, and see if it points to a useful conclusion.

He gives a little background first, noting that he’s been at this for a while, working for a few months before on how screen-readers parse through a web site and do their thing. He’s found methods to get the applications to read certain parts of the site better than just the default, but the real problem is the update of the page via the DOM. There’s just not a reliable way he’s seen to let the software know the page has been changed.

That doesn’t stop him from trying, though, and he goes through seven variations of the same page of information, trying to send something back to the software to let it know there’s something different. Unfortunately, in the end, there just wasn’t a reliable way that he found to get the job done. Not even a Javascript alert() box worked in one of the applications. Even more unfortunately, this problem seems to lie with the screen-reading applications themselves, and not with the content of the page. They’re just not made to handle this sort of page alterations yet.

Posted by Chris Cornutt at 7:08 pm

3.5 rating from 51 votes

Monday, May 1st, 2006

Open Says Me (Accessible Development)

Category: Accessibility, JavaScript, Usability

Pete Forde suggests a method in his new post for making websites that everyone can enjoy, not just the ones that have browsers that natively support the latest bells and whistles. Graceful degredation is one of the larger problems that developers with technologies like Ajax face, but the development method he suggests just might help.

As web developers, we have a serious issue to contend with: completely all-over-the-place support for Ajax. Prototype does a great job of abstracting the various browsers, but there are several pitfalls coming our way.

The good news is that we don’t have to draw a line in the sand. We don’t have to interrupt navigation with warnings about internet settings. We will not point at our potential clients and suggest that without JavaScript and cookies enabled, they will not be able to access the full functionality of our site. With proper planning, we can refactor our site architecture so that people with feature-limited browsers can use a site, albeit with some limits to functionality, but without being presented with an ‘Upgrade or Else!’ style ultimatum. The solution is remarkably simple.

He proposes a solution that is the reverse from most of the methods I’ve read, working from the more basic user’s perspective out to the more advanced. Since “functionality for all” is really the key to keeping users happy and informed, it makes sense to develop a site that can work first there, then have more of the add-ons later.

There’s a series of steps he gives to follow to make sure your development follows this process, as well as a flowchart to get you headed in the right direction:

Posted by Chris Cornutt at 1:14 pm

4.2 rating from 36 votes

Friday, April 28th, 2006 Offline Access and Permanent, Client-Side Storage

Category: Dojo, Examples

Brad Neuberg has written a very thorough article on Offline Access and Permanent, Client-Side Storage, Thanks to Dojo.Storage.

He details his updated work via Moxie, a sample application.

What is is a unified API to provide JavaScript applications with storage. It is a generic front-end to be able to provide all JavaScript applications a consistent API for their storage needs, whether this JavaScript is in a browser, a Firefox plugin, an ActiveX control, using Windows Scripting Host, etc. Further, the storage backends can use whatever mechanism is appropriate; automagically detects its environment and available storage options and selects the most appropriate one.

Future Storage Providers

  • Cookie Storage Provider – uses cookies to persist the hash table
  • Flash Storage Provider – uses Flash’s SharedObjects to persist data
  • ActiveX Storage Provider – uses COM’s File APIs to persist data
  • XPCOM Storage Provider – uses XPCOM’s File APIs to persist data
  • Form Storage Provider – uses the text autosave features of a hidden form to save transient data (the Really Simple History library uses this trick)
  • WHAT WG Storage Provider – uses native browser persistence to store data, as defined by the WHAT Working Group.
  • IE Storage Provider – uses IE’s proprietary abilities to store up to 60K of data.

Moxie: Offline Access

Posted by Dion Almaer at 10:09 am

3.7 rating from 47 votes

Thursday, April 27th, 2006

OpenLaszlo and Dojo Partnership

Category: Dojo, Editorial

The OpenLaszlo and Dojo teams have announced a partnership. The end result is a win-win for both groups, and thus for us. application developers. Dojo is going to get improvements and widgets from OpenLaszlo for us all to use.

The Dojo connection came about as part of our current project to bring OpenLaszlo to multiple runtimes, and to DHTML. We are building separate kernels for each of our runtimes. These are small pieces of code, written in the native dialect of the target (ActionScript 2.0 for Flash 7 and 8, cross-browser JavaScript 1.4 for DHTML, and so on), and providing the runtime abstraction layer upon which the rest of the platform will rest. As we approached the design of the DHTML kernel, it seemed to us that the more we could leverage work being done in the Ajax/DHTML world the better that kernel would turn out.

Dojo quickly stood out as a toolkit with a mature design philosophy, committed and smart collaborators, and (crucially) a package system that would allow us to pick and choose features without adopting the entire toolkit. Our needs are specific, and low level: leak-free event handling, robust media loading, cross-browser DOM APIs, and so on. Dojo is able to provide many of these, so we decided to license it for use within the OpenLaszlo/DHTML kernel.

But Dojo doesn’t provide everything we would want in a DHTML kernel. For example, our kernel exports the concept of a sprite—basically an interactive display primitive, implemented as a MovieClip in Flash 7 and 8, and as a DIV in DHTML. Our thought was: why not contribute these pieces back to Dojo? We’re both open source, with compatible licenses, so a contribution like this repackages code we would write anyway in a form that can be re-used by the broadest possible audience. OpenLaszlo benefits from more smart engineers using and improving the kernel of our DHTML runtime, and the Ajax community gains new libraries within a mainstream toolkit.

Press Release

Posted by Dion Almaer at 8:54 am

4 rating from 23 votes

Monday, April 24th, 2006

S3 Javascript Bindings

There’s a new open-source project to access Amazon’s S3 storage service from Javascript. Creator Les Orchard explains:

  • There’s a SHA1 implementation for JavaScript.
  • The authentication scheme for Amazon’s S3 requires SHA1.
  • JavaScript-based apps can be served up from the S3 domain as files stored via S3.
  • All of this adds up to JavaScript apps hosted on S3 with AJAX-based read/write access to S3 itself.
  • Also: Imagine GreaseMonkey scripts using S3 as a universal configuration pool and long-term data store. (The configuration pool idea, by the way, came from Dave Winer.)

    We’ve talked in the past about offline data storage, whether via Flash or future browser enhancements. Holding data in the user’s own third-party store is a third option for storage, an alternative to conventional online storage as well as offline storage that allows the user to control their own data without having to maintain it locally.

    The service is ideal for Client-SOA apps, where the browser runs the entire UI and makes REST or RPC calls to the server, which responds with raw data. The app itself could presumably load from another URL, your local hard drive, a bookmarklet, or a plugin/extension/GM script (with varying levels of security risk involved).

    There’s already a nice demo app: S3 Ajax Wiki. In this case, the app loads from S3 itself, which is also possible in certain situations:

    Of course, since my demo wiki is sitting in an S3 bucket with a public-write ACL, everything’s open to vandalism and subversion (of the bad variety)- documents and application both. S3Ajax does allow authentication through your S3 credentials, though, so a private group with restrictive S3 ACLs could use this wiki successfully.

    Documentation on the S3 library is currently limited, but you can read more about the S3 Ajax Wiki here.

    Update: As mentioned in the comments below, there’s also a new online API,, that lets you access your own S3 file store from the browser. Right now, the service acts as a proxy, but it looks like they have plans for direct access to S3 in the future.

    Posted by Michael Mahemoff at 4:35 am

    3.6 rating from 22 votes

    Friday, April 14th, 2006

    Morfik Chess Application

    Category: Showcase

    The Morfik team has written a letter to the Ajaxian community, discussing their new chess application, and a lot more:

    Last week we officially opened the Morfik website to the general public and provided for download a fully featured release of the WebOS AppsBuilder for evaluation. I would appreciate it if you could review this release and share with your readers your thoughts on the product. But I would like to quickly say that this not the assistance I am seeking, though it would be nice J.

    On our website we have established ‘Morfik Labs’ where we and some of our test developers are placing AppsBuilder sample examples (with source). These sample applications cover websites, business apps, games, mashups etc. They are at different stages of development and are focused on pushing the edges of what can run in the current breed of browsers. The Chess program in Morfik Labs is an example of this.

    All the sample applications, including the Chess program, have been developed using the AppsBuilder visual designer and a high level language – Java, C#, Basic or Pascal. There is NO hand coding of JavaScript, or use of code snippets etc. It is all compiled into JavaScript for applications running in the browser and native code for the server. We are very keen to see if there is any limit to what can be achieved in the browser using this methodology, i.e. we are treating the browser as platform. It has been pointed out that “The smart developer isn’t one who knows how to implement it [JavaScript], but one who knows where and when to implement itâ€?. Of course the smart developer also needs to know what the limits are empirically and not subjectively.

    Today we released version 0.4 of the Morfik Chess application (release notes below). This version has a chess engine developed with WebOS AppsBuilder using Object Pascal and compiled into pure JavaScript and HTML so that it can run in the browser. It is able to compute at least 2 moves deep. We believe this is the world’s first implementation of a chess engine in JavaScript.

    We are developers, not chess engine experts. We have never written a chess engine before. The code is not yet optimized nor is it the most efficient way of writing a chess engine. Our source code is open and we hope interested individuals will take on the challenge to work with us to take this application or its descendants to the next level. They are also welcome to take the concept/code and independently develop a browser based chess engine/application. This is where we would like your assistance; to find people who would be interested in working with us on the Chess program to see how far browser based applications can be taken in the area of raw computing.

    This endeavor is driven by the belief that the frontiers of browser applications have not yet been reached for three reasons:

    • Current applications written for the browser are limited because they use hand coded JavaScript. Strongly-typed compiled languages follow a rigorous programming model that has made compilers the preferred tool for building large and complex applications. Compiled code is, by definition, more reliable and scalable than interpreted code. Although the client-side code generated by AppsBuilder is JavaScript, rigorous type-checking and enforcement of referential integrity by the compiler produces reliable and scalable AJAX.
    • Browsers ‘raw power’ is progressing significantly due to competition. What was difficult to do yesterday is possible today and will be easy to accomplish tomorrow.
    • The mindset of developers needs to shift further towards the browser, i.e. it is not just a ubiquitous presentation level but also a ubiquitous OS layer. We may remember the days when developers were asked to move from DOS to Windows. How often the concern was raised that Windows based applications ran slower than those in DOS (and anyway it was only fancy graphics)….but as improvements were made the vision and reality of what could be delivered merged. We are today at the same juncture with regards to browsers. We need to change in order to meet the future. And the future is good.

    Morfik Chess

    Posted by Dion Almaer at 10:33 am

    3.5 rating from 34 votes

    Friday, March 24th, 2006

    Ajax Timeouts with Prototype

    Category: Programming, Prototype

    Network problems are only one of the difficulties that can plague Ajax applications, but they can be the most difficult to deal with. How can you check, with a Javascript call, to see if the remote host you’re using is down? A simple call to the server won’t work – the connection would just sit there with no update to the user. So, what’s an alternative? This script, using prototype, that checks the server and, with the help of a timeout setting, can gracefully let the user know it’s inaccessible.

    I’ve been implementing some AJAX goodness in Mayday and other FastFrame apps lately. In my reading of the various pitfalls of AJAX one that popped up repeatedly was how to handle gracefully a network outage or the webserver going down.

    His version borrows ideas from a different post on handling the connection failure, but alters it a bit to get it to cooperate with a prototype setup.

    The real key is in the use of responders combined with a setTimeout to see what the readyState of the connection is. If the timer runs out and there’s still no successful connection, the script errors out with a “network is down” message. Of course, this could be a number of things – the server is down, the network connection between you and it is down, etc. At least it’s a step closer to an application that doesn’t care.

    Posted by Chris Cornutt at 9:32 am

    3.4 rating from 48 votes