Implicit Evaluation with PHP

20 September 2006

Difference between a post and a submission

ASP.net features, by default, a wonderful thing called a viewstate which I wrote about on Monday. However, viewstate is just one technology ASP.net uses to make development on that platform easy. Another is the postback. Postbacks aren’t really a technology at all, just a re-factoring of the general submission patter that’s been around since CGI hit the web well over a decade ago.

The first step to understanding a postback is to consider what exactly happens:

  1. A user fills out a form
  2. The user clicks Save
  3. The form submits to the server, where the forms action is invoked

However, one simple layer of indirection can complicate the logic and simplify the process. Rather than directing your form’s submission to a specific action handler, direct it to a form handler. That handler can grab the view state, apply the submitted values to it, and then invoke the specific desired action. This additional layer makes it trivial to insert validation, provide error prompts, or really to do any common form-related processing that all of your actions would otherwise have.

Though this is already only subtly different from traditional submission design, it provides another interesting feature. By now properly factoring your actions, converting your application design from a traditional postback model to a Web 2.0 Ajax application becomes easy. You already have written all the Web 1.0 code for compatibility and will just be reusing it for Web 2.0, with nothing more than a few Javascript interface wrappers added and perhaps some additional templates.

It’s amazing that such a small change can positively enable so much. That is why good application design is so important. To many, as long as the code works, things are good enough. But that’s really not true. When you code to assumed workflow, you inhibit later changes and improvements. The quickly written code becomes a spider-web of early abortions and a myriad of conditions on output. A properly factored application gains little to no additional complexity as these kinds of changes are desired. But they’re only possible by understanding these subtle differences ahead of time.

No Comments currently posted.

Post a comment on this entry: