All this MVC discussion has been very helpful. There are obviously
many ways to do MVC web apps and I'd love to get a bit of feedback on
the approach we are currently planning for ours before we jump into
coding. Our app is a platform for running econ experiments, each of
which is structured a bit like a multi-player game.
We already have a pretty well developed Model containing the
application logic, and for the web UI we're planning to use Mason for
a number of reasons which I won't get into here. The only reason I
mention it is that our approach does use Mason specific features like
autohandlers/dhandlers.
The directory structure looks something like ...
/C
/autohandler
/login
/register_action
/login_action
/E
/Game1
/autohandler
/submit_decision_action
/display_results_action
/Game2
/autohandler
/submit_decision_action
/display_results_action
/V
/autohandler
/login
/E
/Game1
/autohandler
/decision_submission_view
/results_view
/Game2
/autohandler
/decision_submission_view
/results_view
... where the stuff under /C makes up the Controller(s) and the stuff
under /V the Views. The C components and corresponding autohandlers
are pure Perl (no HTML output) and the V components and autohandlers
are simple templates with minimal code (presentation-related only).
URLs would always point to some action component under /C which would
then call the appropriate view component under /V using the new
sub-request mechanism in Mason 1.1. This would allow us to use
autohandlers as a directory based inheritance mechanism for sharing
Controller code. And we can also use autohandlers as a directory
based inheritance for templates for wrapping page content.
So a Controller would consist of an action component and all of its
autohandlers, and a View would consist of the view component and its
autohandlers.
In order to avoid hard coding paths & URLs, we would use something
like the action table Chris Winters mentioned. This would be a Perl
object with action key to component path mappings, as well as view
name to component path mappings. We'd probably put this action table
as well as some of the font/color type of data together into some
UIConfig class, similar to what Rob Nagler is doing with his Facade.
The appropriate sub-class of UIConfig to use for a given request
would be specified in the autohandlers under /C, with /C/autohandler
providing a default, which could be overridden by
/C/E/Game<n>/autohandler.
One nice feature of this architecture is that it should allow us to
easily create a new Game3 which inherits all actions and views from
Game2. Overriding an action or view could be done by creating a new
UIConfig sub-class which inherits from the one used by Game2 and
overrides the corresponding entry in the action table.
I'm sure there are details that I haven't thought about yet, but any
comments on this structure?
Tear it apart! :-)
--
Ray Zimmerman / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
Sr Research / phone: (607) 255-9645 / Cornell University
Associate / FAX: (815) 377-3932 / Ithaca, NY 14853
