Comments on: Javascript Status Message Display

By: return-path

return-path — Fri, 06 Nov 2009 18:27:03 +0000

Sorry that should be

By: return-path

return-path — Fri, 06 Nov 2009 18:25:38 +0000

Why not add an accessible iframe?

where /show-flash is uncached and reads the cookie through HTTP.

By: Alberto

Alberto — Sat, 17 Jan 2009 19:48:32 +0000

Hi Ian,

Just a quick FYI. I’ve implemented a small python module + js code for TG2 heavily inspired by this article (http://pypi.python.org/pypi/WebFlash/). If using python 2.6 it has no dependency outside the stdlib (else simplejson), JS part has no dependency at all. Thanks for the inspiration!

Alberto

By: bodq

bodq — Mon, 29 Dec 2008 23:18:50 +0000

Ummm, I don’t get it. If you use cookies for this sort of message-passing, what happens if the user has two windows open? I can see all sorts of race conditions happening this way. And since we’re talking Internet, with unpredictable packet drops and reordering, it’s not so unlikely to happen (think about mobile or third-world countries).

Example:

open /a in a new window
send post to /b
get cookie from /b, redirect to /c
/a finished loading, displays the message intended for /c, clears the cookie
/c finished loading, no message

It’s not clear to me whether the onload check happens for every page or just for /c. But even in the latter case, the race is still possible.

By: Ross Lawley

Ross Lawley — Mon, 29 Dec 2008 16:51:57 +0000

In the past I’ve handled flash messages and caching by not caching the whole page, just segments / data. The result was any cached url still contained some minimal business logic. This approach allowed me to display dynamic user data and still have the main database heavy content cached. The benefits of this are its accessible.

In fact the only data I returned from the database when I hit a cached page was the users session data. This provided me an easy way to have dynamic content such as logged in status, flash messages and still have the benefits of a cache.

By: whit

whit — Tue, 23 Dec 2008 00:32:59 +0000

@donovan

you should check out jugl for templating or the javascript db written in javascript. ok… it’s still server side.

re: about how sites should work with javascript

I think this is what separates web applications from websites (or maybe a particular kind of web application from websites in general).

It’s a bit like saying “All gui applications should have a command line interface that is as good as the gui or I’m going home”. especially in the mobile realm, this simply doesn’t make any sense at all anymore.

for better or worse, people are building web application and sometimes even browser implementations for solving specific problems with almost no or severely circumscribed regard to cross browser compatibility. For web sites this would be inaccessible and flippant.

But for web applications, the audience is the market, not the browser. Javascript is being allowed to access some seriously deep things that html and form encoding can’t touch. combined with html5 persistence, and literally the web application is nothing but an easily updatable set of instructions.

By: bruno

bruno — Fri, 19 Dec 2008 08:34:27 +0000

“”" As a reader you should never need Javascript, but as a writer (i.e., editor, commenter, interacter) I don’t see the motivation anymore. “”"

OTHO, using “whole page” caching on the writer interface seems a bit weird. There might indeed be the case of a post handler redirecting to the reader interface after a successfull modification (edit, comment, whatever), but then you obviously want to invalidate the cache to take the modification into account.

This being said, I’m not personnaly dogmatic on “requiring javascript” or not, nor on how to best use it - it really depends on the kind of application and the target audience. So I wouldn’t comment on your design decision to use js for notification here - I just don’t have enough context !-)

By: Ian Bicking

Ian Bicking — Thu, 18 Dec 2008 21:17:21 +0000

On principle I used to feel strongly that applications shouldn’t require Javascript. Then at some time I realized it was just principle, and not real reasons, so I’ve become much more lax. As a reader you should never need Javascript, but as a writer (i.e., editor, commenter, interacter) I don’t see the motivation anymore.

By: Simon Willison

Simon Willison — Thu, 18 Dec 2008 09:22:53 +0000

I still stick to the premise that applications should be usable without JavaScript, but usability enhanced when you ARE using JavaScript. Unfortunately I’d rate this kind of status message as something that is required to make the site usable at all. I’d love a better solution to this problem though.

By: Andrew Hedges

Andrew Hedges — Thu, 18 Dec 2008 07:18:42 +0000

This is one of those techniques you look at and say, “Why didn’t I think of that?” I may just use it. Status messages aren’t usually critical, so I think it could be justified to use this in certain environments despite the lack of accessibility for folks w/out JavaScript (which in addition to the other cases discussed above includes many mobile clients).