Re: MVC Topic Joy
> 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. It sounds like you have a system that works well for you, and that's what really matters. I would probably try to get this default HTML that View.pm puts out into the same place the rest of your HTML is created, especially since it seems like View.pm is responsible for interpreting request data and calling methods on model objects. (View.pm is maybe a somewhat misleading name, since it isn't the part that generates the HTML "view".) - Perrin
Re: MVC Topic Joy
Jon Robison wrote: > 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. The confusion here is that your View.pm is not a view, but a controller. > It's the html module's job to fill the return from view_data > with the correct information. Then it sounds like the html module is your view. It's the part that accepts data and generates HTML. - Perrin
Re: MVC Topic Joy
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
Re: MVC Topic Joy
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
