CGI::Prototype, Part Three
In the last two columns, I introduced my CGI::Prototype generic controller framework. This time, let’s continue the examination with a description of a real workhorse subclass, CGI::Prototype::Hidden.
In the last two columns, I introduced my CGI::Prototype generic controller framework. This time, let’s continue the examination with a description of a real workhorse subclass, CGI::Prototype::Hidden.
The CGI::Prototype framework can be used to write applications, but lacks the concrete means by which the state of the application can be deduced. I wrote the code expecting that various strategies for state dispatch (hidden fields, cookies, server-side databases, mangled URLs) would be coded as subclasses of CGI::Prototype. The first to be coded is hidden fields, implemented as CGI::Prototype::Hidden.
For CGI::Prototype::Hidden (CGIPH), the state must be a simple, arbitrary keyword: something that matches /^\w+$/. The state is used to select a particular class for the controller, along with the default template for that class. Once a state’s been selected, the corresponding class is loaded into the program (unless already defined), and used to determine the next step in the program. This “lazy loading” behavior permits a minimum of loading for CGI programs: at most, two different state-named classes are loaded per web hit.
CGIPH also defines a “wrapper” template to provide common definitions, headers, and footers for the processed templates, and a means by which the templates can be found “next to” the class source files. More on those later.
