I tried to make Tempura tonight. It sounded like a good idea. I made some batter and chopped some vegetables. I was talking to Louise and I told her what I was making and she said that I wouldn’t be able to deep fry the vegetables in olive oil, which is the only kind of oil we stock. Nuts I thought. I resorted to shallow frying and this didn’t really work out. The batter didn’t crisp properly and clumped instead of thinly coating the vegetables.

The recipe I followed included a sauce for dipping in. That was pretty good. Soy, some honey and some vinegar and it was really tasty. Lucky really.

I made the Tempura because I fancied a change, but it wasn’t that great and I probably won’t bother again as it’s quite a bit of work for just some vegetables really.

After reading LShift’s NMK case study I started reading one of their references, Modeling Web Interactions. This was an interesting research paper that looked at two problems in developing web software. The first was the problem of getting the right input from forms, the second was the problem of users opening secondary windows and following two paths through a system, resulting in one becoming out of date, because the server only stores one set of data.

The second is a tricky problem without a great solution. They recommended time stamping the forms. At least this way if the user does submit an out of date form this problem can be caught and the user warned. However, they suggest no technique for recovering from the situation.

They also don’t really take into account security problems. E.g. anything sent to the client becomes mutable and anything received from the client can’t really be trusted. This is an impossible problem really, but it directly contradicts some of the things required to combat the above issue. If infomation is stored on the client then there’s no risk of that page becoming outdated as the server has no state and simply relies on the client to do that. However, if that state is untrustable…

The other problem outlined in Modeling is more interesting and their techniques more applicable. They discuss the problems of forms not matching the programs required to process the data and the problem of multistage conversations between user and system. Whilst they provide little in the way of solutions for the second part, they find a radical solution to the first. They create a programming language which is type checked with respect to web forms. A form definition is created and as a form-consuming program is installed on the server it can be checked against that form definition for correctness. The authors advocate creating type-checking facilities for all the languages used in web programming, which is obviously slightly useless. However, I think that their idea can still be applied.

The simple way to do it is with a code generator for your favourite language. The generator takes a form definition and produces objects/functions to first of all create an instance of that form and secondly handle the form when it is submitted. This generation ensures consistency and also allows for validation etc to be built in easily, preventing mistakes and retyping the same fucking validation routines. This is an easy and safe way to statically check forms. However, two problems arise.

Firstly the HTML output by the object can’t be decorated very easily. Solutions here include generating XML that is then transformed by a configurable snippet of XSLT or by exposing the output form HTML tree to editing somehow (probably via a DOM like mechanism). XSLT is best as it’s much easier to add a large amount of extra markup, as is required with a commercial web page.

A more serious problem is that of forms which vary dynamically. E.g. a shopping cart form will have a quantity and an ID field for every item in that cart. A statically created form can’t replicate sections and the processor object can’t retrieve and check the data. The solution here is to be able to define possibly repeating sections in the original form definition and to create a form generator that can dynamically repeat the right sections. The processor will be similarly specialised. The only tricky part is communicating between the generator and the processor the number of repetitions that have been created. The generator, or simply the tally, can be stored in the state, but care must be taken to ensure that the form coming back in conforms to the pattern sent out.