Log in

No account? Create an account

Previous Entry | Next Entry

More web app ranting.

The theory is that one shouldn't be able to tell what parts of a site are dynamically generated and which parts are static, except that the dynamic parts are dynamic. The W3 Style Guide makes some specific reccomendations. Dates as heirarchy make sense, because they won't conflict over time, so you can keep the same URL valid forever, without namespace collision with future content. URLs specific to a certain set of server software should be avoided: no cgi-bin, no .cgi, and if your resource could theoretically be served up in a new content type in the future, no file extensions. It may be .html now, but maybe next year .xml will be in vogue, and ten years from now, .xht7 files will be the rage. If you leave it off and let MIME types do the describing.

For a web app framework, this means that whether or not to dynamically generate a page can't be drawn from the URL in the general case. Should /products/foospray be static or dynamic? It should probably be static, updated when product information changes. Perhaps the output code would filter the page to include information about a user's shopping cart, but hopefully that could be handled client-side, so that every user accessing the same URL at a similar time sees the same page.

One could probably conclude that locating a web app at a particular URL (or collection of URL space) is not the best option for flexibility. One needs a level of indirection for large sites, so that dynamic requests get handled by the right handlers, and static pages are served as fast as the machine can do it.

In an apache-like web server, I'd like apps to be able to be named independently of their URL, so that something like mod_rewrite can direct requests to the right app. I can imagine this registration resembling registering a remote procedure — after all, most web app frameworks have an entry point that looks remarkably like handle_request(request_object).

Perhaps it would look like this: RegisterApplication shoppingcart /usr/bin/carthandler Route "/products/([0-9a-z]+)(.*)" shoppingcart product=$1 info=$2 URLFor product,info "/products/#{product}#{info}" It's a little ugly, but I think it would work really well. The URL parsing is handled by the web server, where I think it belongs, but enough context about the request is passed on to the web app that it can make self-referential URLs without too much problem. How the arguments are passed to an application process is grounds for another rant, not this one which is more concerned with routing and URL spaces.

The neat thing about that is that one can re-arrange the URLs in the web server, and assign them a semantic meaning there. If one wanted to develop a standard for configuring these things in a webserver-independent way, that would be nice, but hardly neccesary if the app had enough information to just do the Right Thing.

I think a limitation of having user-exposed keys like URLs is that they are subject to configuration, not just being simple opaque identifiers. It's not as simple as an auto-numbered field in a database. URLs have to be designed, not just created. Most non-trivial systems are going to have to have some configuration of their URL spaces, because auto-generation just isn't going to get it right.

In the example above, the instructions for building a URL from a keyed set of information is provided in the configuration. This can be passed on to the app, so that it can generate URLs refering to itself and to others, without major hassle and with a central, well-defined place of control. No need to repeat yourself all over the code, or make undue assumptions (like that /appname/thiing1/thing2 is magically going to be self-referential.)


( 9 comments — Leave a comment )
Feb. 2nd, 2005 10:00 pm (UTC)
I like reading your posts on How Things Should Be.
Feb. 2nd, 2005 10:01 pm (UTC)
Speaking of which, I just got The Design of Every Day Things from the library today.
Feb. 2nd, 2005 11:21 pm (UTC)
I like Norman’s ideas about physical things but not so much about digital things.
Feb. 3rd, 2005 12:28 am (UTC)
I think I see what you mean. On page 27, he suggests as a good interface the single-line LCD screen with buttons to scroll through a menu (one item at a time) and select items. That's a common interface, now. I rather dislike it.
Feb. 3rd, 2005 12:37 am (UTC)

I use that damnable interface on printers, and it sucks. Takes an hour to input an IP address, and it's hard to navigate. Brilliantly few buttons, but universally sucky as an interface.
Feb. 3rd, 2005 10:03 am (UTC)
Even worse: Printers without. I spent several hours trying to find the right software to enter an IP address in a networked printer with no control panel.
Feb. 3rd, 2005 10:51 am (UTC)
Heh. At least there, I know who to piss and moan at.
Feb. 7th, 2005 11:28 am (UTC)
I concur.

But what truly baffles me is that none of the general writing on Good Design over the past 20 years discusses ecological sustainability at all.

I mean, we've had a few nerds like Norman who understand that Good Design ... actually thinking about anything we create ... is a powerful force and a good thing to do. It makes economic sense, and it makes people's lives better.

The truth is, Good Design could save the world. Products that ensure we have more clean air to breathe are usable in a broad and important sense. Preserving our ecosystems make economic sense and make people's lives better, and can fit right in with the process of usable design. Yet somehow, the most vocal people thinking about design have entirely failed to realize this.

There are books on ecological design, of course, but the tragedy is that it's treated over here, as a separate topic from usability, from making things that are just generally good.

I recommend Cradle to Cradle for its thesis. If you understand what they're getting at you just have to skim it.
Feb. 7th, 2005 01:45 pm (UTC)
My shopping cart uses mod_rewrite to pass the URI to my code, which breaks it up and tries to identify the pieces from database information, which stores product names, categories, and their relationship. Any product name by itself will resolve to one of its URIs. For example, http://spartacusleathers.com/collar-with-nipple-clamps This also made it easy to keep the old URIs from breaking, since they were based on product ID numbers, which I kept. I do wish it was more abstracted, bu t at least I can have URIs that won't break if I recategorize the files, and I can still have categories (no matter how good my navigation is, I think users like hierarchical URIs).
( 9 comments — Leave a comment )