Essentially a Dispatch.pm module, which simply looks at the url string params and sets a Handler based upon the value of the "action" param. (After handling security, etc.).
In most cases the Handler is set to "view", in which case View.pm instantiates other modules objects, (and those instantiations use other url string data to determine what to construct into the object). View then just spits out the default head, body (created with the other objects) and footer. All of the "real" work is done by the other modules. View.pm could care less what comes back from $html_obj->view_data. It just adds the result to $body. It's the html module's job to fill the return from view_data with the correct information. Hope this explanation serves. Like I said, I can't lay claim to being a guru ;-) --Jon Perrin Harkins wrote: > > Jon Robison wrote: > > I should never really have to edit > > #3 (the Viewer), because the HTML construction should be done in #2. If > > I find myself editing my viewer to accomodate some function I am adding > > to the overall system, I know I need to re-think what I am doing. > > In an MVC system, you would definitely need to edit the controller any > time you change the input side of the user interface. You may or may > not need to change the model and view as well. > > Which part handles taking the user input, figuring out which methods to > call on the model objects, and choosing a view (usually a template) to > show? This is all stuff that the controller would do in an MVC system, > and you don't seem to have one in your description. If you don't have a > controller, you will end up wedging that stuff into the model objects > which makes them a lot less reusable. > > Don't get me wrong: a basic script + a template is still better than a > basic script + a bunch of print statements, but there is value in the > separation of the controller and the model too. > > - Perrin
