I recently wrote an API callback script that performed some heavy calculations and took a long time to return. To keep the user from having to wait, I wanted to have the script immediately return cached results and asynchronously process the calculations. There are a few partial solutions on the web but none of them properly deal with sites using HTTPS, so here's my solution:
One of the features I'm most excited about in Drupal 7 is the greatly improved flexibility of installation profiles. However, documentation on writing an installation profile for Drupal 7 currently doesn't exist, so I thought I'd change that. Here's what I've discovered by reading through the code.
Soon after I first implemented AHAH-based form refreshing in my Facebook-style Statuses module for the Drupal content management system, I realized that the process created something of a workflow problem. Users would go and post a message like normal, and then the form -- and the links on it -- would refresh via AHAH. Essentially, when a user clicked the submit button on the form, some JavaScript would silently open another page (the "callback" page) in the background. That page would generate a new copy of the form, which would then be copied and pasted over the form that had just been submitted.
The problem was, that new copy of the form was generated on the callback page, and it had no way of knowing from what page it had been called. In other words, if the script generating the form wanted to know what the current page was, instead of getting the URL of the page on which the form originally appeared, it would get the URL of the callback page. This became a problem when dealing with links, because links often include a "destination" parameter so that when a user takes an action after clicking the link they will be returned to the appropriate place. For example, an "edit" link for a message would typically have a "destination" parameter in the URL so that when a user saved the edits, the browser would automatically send the user back to the page on which the edit link was clicked. In HTML, such a link would look like this:
I recently did some work for a client that involved multi-page forms. Specifically, the client wanted a page where users could choose one of five forms, each of which had about ten steps with one question each. Users had to be able to move forward and backwards through the forms, with their data saved when they finished.
I knew a lot about working with forms in Drupal, although I'd never actually worked that extensively with multi-paged forms. But I did my research, and luckily there are some nice tutorials out there. However, most of these were specifically for forms with only two pages, or covered older versions of Drupal, or were crazy complicated. There is a great tutorial at pingVision which I unfortunately found after the fact, but this also doesn't cover a "back" button.
So, here's an example of what I came up with. It's a little clumsy, and there's probably room for simplification, but it works. You can move back and forward in the form and all of your data stays inputted without getting mysteriously wiped away.
I use this trick all the time, practically every day in fact when I'm building a website. When you need to test a PHP snippet or you want to find out how something responds -- you want to see the structure that taxonomy_get_tree() returns, for example, or you forgot what the structure of the data returned from a multi-select form element is -- you can use this shortcut instead of going through the whole tedious process of writing a module or running the risk of blowing up your site by saving the PHP in a node.
