Web app design

The realm of Web app design is really pretty big. I've worked with it since the 90's, of course, but ... a lot has happened rather recently, and I'm still only scratching the surface. I think it's safe to say that it will continue to change.

The underlying structure of any Web application is, of course, a set of files on a disk somewhere. So at the lowest possible level, when specifying a Web application we're actually specifying a set of files. A structured set of files is a product. I'm going to call it that for now, because I want to drive home the idea that the notion of a product is a more general thing - it's a thing that properly belongs in C::Decl, not in a library domain. It's part and parcel of files and directories, because it is a set of files in directories.

So we're going to have a product template structure, and one possible expression of that product template structure is going to be ... well - hold back a little, because obviously there will be a variety of different types of Web app as well (e.g. a LAMP PHP site, a Google App Engine Python site, and so on). The commonality of these types of Web app is that they're made up of pages and supporting files - they all consist of a set of server code in one language or another which generates HTML, and they all include CSS and Javascript.

Earlier today I posted on the "HTML5 boilerplate". This is at least part of what goes into a Web app template. I'd go so far as to say that the basic page template is also part of that macro. And make no mistake; the boilerplate is a macro that we will never see in our specific Web app definition.

Some Javascript and some CSS will also be part of the boilerplate.

The components of a Web app thus become: a specific database and table definitions within that database (aside: some table definitions will probably end up in boilerplate and component macros as well), a boilerplate and sets of imported components, some basic publishing actions to be carried out for different stages of the game (which could also go into boilerplate, actually), and the list of pages/application areas that will show up in the final application.

The only way to work this out is to start building Websites. My initial goal is the Depatentizer (8 days left, haha), but some smaller apps might also be a good idea. And then I want to rebuild Despammed, and maybe even Techspex.

I've been prowling around looking for insight, and so the rest of this post is a link dump about PHP site building (mostly).

Oh, wait: a mother lode of so-called "transaction patterns" used in a toolkit for building database administration sites. It is incredibly detailed. These transaction patterns, by the way, constitute a language for user-level interaction with Websites that is not restricted to the Web domain - they'll work just fine in the Wx context as well. So they should definitely be analyzed, but they can't just be relegated to WWW::Publisher. I'm not really sure where they should go. Probably a new domain. Database::Declarative? I just don't know!

Anyway, that link is brilliant. Brings up the MVC architectural pattern, too - again, this is a solid concept that should be highlighted somewhere, but not in WWW::Publisher. The link there is to the same site, and it includes more than MVC; it's an overview of his entire methodology, some of which I don't care for, but still - wow! Great find. (Building up to a PHP sample app, which is where I found it.)

Now for the link dump.

• DBI for PHP is PDO.
• CPAN for PHP is Pear: Pear coding standards.
• Writing web apps in UML... Mentions WebML (the Web modeling language) - neat!
• Units of Work (UoW pattern) in PHP.
• AJAX overview article. Haven't read all of it.
• Oh, oh, oh - this is also brilliant: a blueprint for PHP Web apps with a mindmap!
• A follow-up article from that series (which mostly never got written, sadly): the bootstrap. This would go into the boilerplate.
• Flourish library - most interesting to me for its abstraction layer over a variety of databases, allowing you to write a Standard Query Language that will be munged into what the specific database needs. That deserves some brain picking.
• Smarty is a PHP template library. The link is a sample app.
• Now, for something completely different: MVC setup in Node.js server-side Javascript. Now technically a Web app definition should be relatively identical whether we're writing for PHP or Javascript on the server, so .... this also needs thinking about.
• Canvas whiteboard with chat using a web socket. That is a collaborative tool that would be useful on sproggler. And any tutoring site.
• A thoughtful article on prototyping and customer immediacy in the early days of a site. Some components for quick feedback should go into the boilerplate.

So there you go. Lots and lots of material to digest. Remember: the only way this will work is to write lots and lots of little Websites. I'm thinking of following that blog with Webapps on it, and doing as much or as little of each as I want to in one sitting, say. A lot of the components of these Webapps should break down into components rather easily, and then I should be able to snap together a site in minutes!