in reply to Refining the CGI process through structure and templates
description is a plain string used as an identifier for the page. It currently provides data for the template's <TITLE> tag. This is probably not so hot.PAGENAME=> {description =>$desc, traverse_list =>{pagename_1 => 1, pagename_2 => 0, ...}, traverse_sub =>\&sub, validator =>\&sub, errorhandler =>\&sub, template =>$filepath, postsubmit =>\&sub, params =>[$param1, $param2...]}
traverse_list is an anonymous hash which stores which pages the current page could link to. The key should be a PAGENAME, and the value of the key determines if the postsubmit subroutine should be called when moving to that page.
traverse_sub is a sub ref which determines which page should be displayed next. It returns a string, which should match one of the keys in traverse_list. It is passed 2 variables, $vars and $errorcode. $vars is a hash ref used to populate the template. $errorcode is generated by the page's errorhandler.
validator is a sub ref used to validate data or business rules. I envision it as returning an integer code, or a bitmap.
errorhandler is a sub ref. It's little experimental -- I picture it being called if postsubmit fails horribly. I was planning to eval postsubmit and call errorhandler if it died, but I'm thinking of expanding its scope. *shrug*
template is a string containing the path to this page's TT2 encoded HTML template.
postsubmit is a reference to a subroutine called after validation. Like traverse_sub, it's passed $vars and $errorcode. If you need to hit a DB, or process user input in some fashion, this is place to do it.
params defines a list of html parameters which will "be sticky" (is that the right term), and be passed as hidden HTML input fields.
In my CST, I will polish the engine and post it. I appreciate the replies and /msgs I've gotten so far, and am trying to incorporate them into the changes I'm making; please let me know if you've got more.
|
---|