For a while I've been looking at some interesting techniques for improved state tracking for web applications. Seaside and plt scheme webserver are using continuations to improve session handling, and have a nice clean code while at it. What does this mean? Continuations are a functional goto. They allow you to capture and save the state of an application, and possibly to return to it at any time. You could think of it as a snapshot of the current state of the application. Well, not exactly, but for the current discussion this will suffice.
The problem with wizards, druids, controlled sequences et.al. in web applications stems from the stateless nature of the web and the lack of control over the client's actions. What will happen if you open several times different steps of the druid in your web browser? How will you know which window requests an update? It is easy to say "Oh, the last update is the only valid one", but you will quickly run into severe non-deterministic mess.
This is where continuations based webservers excell. They can automagically track sequences of page requests, rather than have only one session state at a time. Essentially instead of a string of requests, you can track a tree of requests. They achieve that by using a very nice nifty trick - for each captured continuation, generate a unique url, so when the client performs an action, for example submits a form, you execute that particular continuation. If you view a druid's lifetime as a transaction lifetime, you can see that on final commit only the state coming with the last continuation is commited, and the rest discarded as speculative/of no use anymore.
How can we mimic that in php so that Drupal can benefit from it? I'll start with the easy bit. Wizards naturally work via post requests. So we can stop worrying about bot friendly urls - they ignore them, and anyway, we don't usually care about bots discovering form submissions. For each request we can append to the generated form actions a unique random url, which corresponds to the session state at that particular moment. We can store a copy of the session in db, indexing it with the generated unique id for future use. It is good to store as well a reference to the "calling" session state, so we can clean up at the end of the transaction. This way when we finish with the wizard, we can sanitize the database.
From a typical php application's point of view an analogue of the continuations will be the current session. This is what keeps the state. It is not a real continuation. If you want proper first-class continuations in php you need to do a lot of extra work, so I'll not discuss it today. If we want to capture the "php state" we just create a deep copy of the session variable. Be careful, because not every php object is serializeable. You might need to write your own serialization procedures
yes, the so called wizard api
which is basically the forms api, with a few extensions
In an e-commerse setting, imagine you open a new checkout window/tab. It will display the current shopping cart contents. From the original window you continue to shop. Normally the checkout window won't be updated, although you can deploy an ajaxian solution to track the updates. The user-obvious behaviour of the checkout window will be to work with the displayed items,but storing the item data in the forms has quite a few including security related drawbacks. The proposed solution will make this "time travel" work fine. An alternaive will be to make extra checks for the correctness of the checkout window, so the shoppers are not misinformed what are they buying.
this might a nice feature for an ecommerce site. we already preserve your cart but this could preserve you 'recently viewed products' and your current page (address entry, ...).
do you have in mind places where this would be used?