Raible Designs

Ajax webapps are cool, but non-javascript versions still needed

I think we can all probably learn a lesson from Google. I've heard that GMail is the "gold standard" for Ajax applications. If that's the case, then you should note that they've recently added a "basic HTML" link to the bottom of their pages. With this link, you can view your e-mail using the old way: Yahoo-style, no-JavaScript-needed. My guess is they added it because of demand, or simply to compete with other providers who have this feature. I think it's a good lesson though: use Ajax features in webapps where appropriate, but don't make JavaScript necessary to use your app.

A couple of Ajax features I've been thinking of developing:

Saving forms with XMLHttpRequest: just display a success message at the top, and switch the "Cancel" button to "Done". Since the form's content doesn't change, this seems like a reasonable use of the technology.
Switching out entire "content" <div> elements. Most of my apps have a <div id="content">, so it'd probably pretty easy to just replace that in response to button and link clicks. Of course, the hard part is having the requested server-side object load the view template, process it, and send back the content. This is probably more trouble than it's worth.

Posted in Java at Mar 07 2005, 07:42:18 AM MST 13 Comments

/** * Create function which will subtitute parameters in the template by their values. * Use construction "${expr}" to insert result of the evaluation of the expression * expr in place of the construction. * * Use unicode escapes to prevent parsing of the symbols. * * @param template a string with template * @return parsed template as function * * @author (c)1999 Volodymyr M. Lisivka */ function compileTemplate(template) { template=template.replace(/"/g,"\\\""); template=template.replace(/\n/g,"\\\n"); template=template.replace(/\$\{([^\}]+)\}/g,function($0,$1){return '"+('+$1.replace(/\\\"/g,'"')+')+"'}); var str='var f=function(params){with(params){var str="'+template+'"; return str;}}; f'; return eval(str); }

//Compile template var urlTemplate=compileTemplate('${++counter}. ${description} ${longDescription}'); ... //Use template var counter=0; var item=urlTemplate({url:'http://google.com',description:'google.com',longDescription:'Popular search engine.'});

function compileElement(elementId) { //Get element by it ID var element=document.getElementById(elementId); //Use inner HTML of the element as template var template=compileTemplate(new String(element.innerHTML)); //Create function to replace content of the element by the filled template var f=function(params){ var str=template(params); element.innerHTML=str; }; return f; }

Comments:

Hi -

Making JavaScript-only versions is definitely not the only option. I think it depends on what you are developing, who is the audience, etc. It will be cool to see if we can have components which can failback themselves.

Saving forms: This is a no-brainer, and fits into background validation. Send the info, show validation errors if that it the case, else give feedback that the form was sent. We are doing this, and it is interesting. Of course, if you DO want to change the page then you can go back to 'normal' mode, or you can send back a redirect.

Switching content: We have code that lets the server send back XML, and the client replaces the part of the dom based on an id, or content tags.

Dion

Posted by Dion Almaer on March 07, 2005 at 04:19 PM MST #

Matt, I've been looking at the same thing and you might want to take a look at TrimPath's JavaScript Templates project: http://trimpath.com/project/wiki/JavaScriptTemplates
I'm looking at using this project to do the content div swapping that you mention.

Posted by Scott Mitchell on March 07, 2005 at 04:21 PM MST #

We developed a product using ajax-style of development back in '99. It was powerful, but a real pain. There were so many little problems we ran into with frames and javascript. Every browser version had its own set of quirks. It's also harder to test in an automated way. (And impossible to automatically test all browser versions.) We were forced to use a functional testing product that automates IE through COM (instead of HttpUnit because of its limited JavaScript support).

The complication of the technologies used makes clean design more difficult, I think. I like the idea of having as much of the (display) logic in Java as possible. Plus you'll find yourself jumping through hoops to get the JavaScript to work correctly for all browser versions.

We are now developing a new product and going with straight frameless HTML with as little JavaScript as we can get away with. I think our customers will be happier with us overall as we'll be able to deliver a higher quality product in less time.

We plan on emulating frames via HTML tables (or equiv) and doing field level verification on the server side. It might be a little slower, but I'd rather buy a few more servers or T-1s than add risk to our software.

No sir. You can keep that technology to yourself.

Posted by Michael Slattery on March 08, 2005 at 01:56 AM MST #

I'd to see some figures on people that don't have Javascript-enabled browsers. The people smart enough to figure out how to turn javascript off are almost assuredly smart enough to use a better browser without the same vunerabilities that IE has, so are you really hurting yourself if your site doesn't work for 1% of the web population? Maybe it's higher than one percent, that's why I'm curious about the actual numbers.

Posted by PJ Hyett on March 08, 2005 at 04:03 AM MST #

I'm not sure if switching 'content'-divs is really a nice solution. Doing this too much would take us back to the bookmarkability-problem of frames, no?

Posted by SotA on March 08, 2005 at 07:40 AM MST #

I have recently build an application that does content reloading via divs and form posting (although I haven't gone as far as turning off any buttons). The application looks and feels like a portal and that was intentional for my users. It is all XmlHttpRequest based, with form serialization in both XML and traditional url-form encoded formats and it works great. One of the things that made it nice was that when a user selects an from a tree, which is an organization structure in the app, the other 'portlets' update independantly of each other; multi-threaded if you will. The data is fairly small for each portlet so it is lightning fast and the users really like it. I even have the beginnings of a min/max/close buttons like you see on regular portals, all javascript.

The only real problem I had was the tree which is built via a javascript library and I could get it to load dynamically into its own 'portlet' div and still work. I had a hack for Firefox but IE wasn't very helpful. I'm not a wiz as javascript yet so I'm sure there is a solution, and I've seen some suggestions elsewhere but haven't had time to persue them. Ultimately though I have thought about making the underpinnings of the UI an open source project. The backend happens to be WebWork and Velocity but that was just a personal choice.

Posted by Robert McIntosh on March 08, 2005 at 04:15 PM MST #

The bookmarkability problem will occur with Ajax.

Posted by Michael Slattery on March 08, 2005 at 05:22 PM MST #

Yes, bookmarkability will not occur, if an application needs that. However most of the apps I work with don't need, nor do I want bookmarks, such as most data entry apps. From my experience, bookmarks are more desireable in a browsing application and not a manipulating application. If you need back and forward button functionality, then a method such as hidden iframes needs to be used. Google Maps uses this technique, where the data is loaded via a hidden iframe, and the document from that iframe basically executes a javascript function in the parent windows, supply XML data to it, so you get the ability to use the back button and such while the display refreshes with the whole page refreshing. In some cases you could even use the iframe approach with bookmarks, and Google maps has a way to do that as well.

Posted by Robert McIntosh on March 08, 2005 at 05:31 PM MST #

I had to make my own blog about ajax problems to stop the madness: http://jroller.com/comments/MikeSlattery/Weblog/ajax_is_a_mistake

Posted by Michael Slattery on March 09, 2005 at 03:39 AM MST #

> Matt, I've been looking at the same thing and you might want to take a look at TrimPath's
> JavaScript Templates project: http://trimpath.com/project/wiki/JavaScriptTemplates
> I'm looking at using this project to do the content div swapping that you mention.
Why not just use a very small function for same thing, like this:

Usage:

Result:

1. google.com Popular search engine.

A variant with construction to allow emebeded javascript a bit larger so I don't include it here. (Copied from my JavaScript Server Pages project which is under LGPL license).

Posted by Volodymyr M. Lisivka on March 09, 2005 at 05:12 PM MST #

Your site has problem with HTML escapes in previev mode - the HTML is not escaped before placing in the textarea.

Posted by Volodymyr M. Lisivka on March 09, 2005 at 05:14 PM MST #

The best way to use templates in DHTML is to get template from HTML, like that:

so you can write HTML with parameters:

<div id="userNameFields">
<input type="text" name="firstName" value="${firstName}" /> <br/>
<input type="text" name="lastName" value="${lastName}" /> <br/>
</div>

then compile it:

userNameFields=compileElement('userNameFields');

and then just call it when needed:

userNameFields({firstName:'Volodymyr', lastName:'Lisivka'});

It is very pretty in conjuction with JSONRPC.

Posted by Volodymyr M. Lisivka on March 09, 2005 at 05:46 PM MST #

I too looked at TrimPath and it looks like a pretty good library. The difference between the suggested regex function and trimpath is that trimpath can do more than just param substituting, such as looping through arrays and objects, as well as other stuff.

Posted by Robert McIntosh on March 09, 2005 at 06:01 PM MST #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

Ajax webapps are cool, but non-javascript versions still needed