The extraordinary WebGUI scratch pad

How often have you encountered a situation where you wish you could retain very specific information between page loads.  Sometimes that information is state-ful.  Other times it is to hold information through a process of form submits.  The most common answer to retaining this data is cookie storage.  In WebGUI, it isn't necessary for the developer to concern themselves with where the data is stored, only in how!

Every WebGUI process has a session.  As a component of most sessions, there is a scratch pad object called WebGUI::Session::Scratch, which is accessed by the reference $session->scratch.  With 'scratch', you have all you need to retain whatever data you want for the life of the session, or shorter if you wish.

By using scratch->set(<name>, <value>), you can define a name/value pair for your information.  Virtually any name can define any scalar data.  Retrieving that data is as simple as scratch->get(<name>).  Your stored scalar data is returned to you intact.  Complimenting these set/get methods is scratch->delete(<name>) when you really don't need the scratch value retained anymore, for example as a flag for some flow control process.

Interestingly, you are not restricted to scalar data if you use a simple trick.  My favorite use of scratch is to store a stringified JSON object.  By adding 'use JSON' to my loaded modules and handling my data with 'to_json' and 'from_json', very complex structures can be stored in a single scratch name/value pair.

This has been helpful to me when handling complex registration page processing where 508 compliance was necessary.  Both a Java-Script enabled registration process and a multi-page form entry process were built side-by-side to handle both situations smoothly.  By intelligent use of the scratch pad, I was able to retain previous CGI form entries, monitor each page's validation and process position, and recover all components at the end for the final submit.

In this way I could allow the Java-Script enabled process to work as expected and compliment it with non-Java-Script entry processing validated along every step of the way.  Additionally, because some form requirements changed based on previous entries, I was able to make each non-JS page perform in concert with the dynamic page just be checking my scratch state values, and rendering the new page based upon that data.

Managing all this data using cookies would have been much more cumbersome and harder to test.  Instead, I allowed WebGUI to do what it does well; retain session, and then let my session retain my data.  Extending scratch to hold complex data was just the icing on the cake.

Stephen Opal