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
MVC Topic Joy
I can make no claims to being any kind of exceptional programmer. Heck, I don't even claim to be half bad. But this topic has really revealed to me that the concept of MVC means many things to many people. In the end, I think what I have concluded, at least for my purposes, is simply this: 1. Modules that deal with core data (i.e. that read/write to the database) shall never output HTML/XML/Whatever. Just hashed (complex) data, or simple arrays. 2. Modules that DO create HTML/XML/Whatever should take the core level data and make the html 3. Modules that present the data should take the html produced by #2 above, wrap as needed in start and end tags, and spit out the resulting page. They data output by #2 shouldn't matter to this module. Whereas I know this is overly simplistic, I think that as a rule, it should work. If I catch myself sticking HTML into the output from my DBI call before I return the final result, I know I have broken my rule and should re-think whatever I am doing. 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. Simplistic, yes. Workable, yes. It meets the KISS principle, at least. ;-) Comments, disagreements, smacks across the virtual face willingly accepted. --Jon Robison
