I have sought similar and similarly found no all-in-one solution for my stuff. What I did come up with is HTML::FormValidator, which does some HTML form validation, but the validation isn't fully to my taste because I want synchronous JavaScript and Perl validation, or rather, JavaScript regular expression validation to save some round trips, which is fed from the Perl code / a database.

The one thing I've come up with which I like better than your approach is dividing the single pages into unlinked single pages and having an external structure that defines the order of my pages, like so :

my @pageorder = qw(welcome address notify done);

my %pages = {
  "welcome" => \&page_welcome;
  "address" => \&page_address;
  "notify"  => \&page_notify;
  "done"    => \&page_done;
};

my %validators = {
  "welcome" => \&validate_welcome;
  "address" => \&validate_address;
  "notify"  => \&validate_notify;
  "done"    => \&validate_done;
};
[download]

but as you see, my layout is still mostly linear. Having some tree-like paths would be interesting and with my approach, the navigation component can be abstracted, but I haven't found a nice and good way to implement the chosen path (calling all possible validators isn't an option in a non-linear graph anymore :-) ).

I like HTML::FormValidator, too. There is a review of it available.

-mark

Not because it solves the problem you want (it doesn't), but because the entire "state machine" philosophy it uses is (at a guess) going to be a good fit for your problem and is similar to the direction you are heading. Therefore seeing a mature implementation of those ideas in another context is likely to shorten the path between you and some key design ideas you will find helpful.

Remember that the most interesting innovations tend to happen when someone finds a way of taking person A's well-developed theories and apply them to person B's problem...

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...]}
[download]

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.