0

I have a web application written in Perl with a controller, some "views" and some "Models". Each "Model" is corresponding to one "View". The controller (one file) creates an Model object corresponding to each view (view is a CGI argument) then retrieve the view from the module it has just created.

Indeed, this should be bad thing but can you argue a bit more about it.

My first idea was that since the object "Model" depends upon the "view", then the "model" is actually a view.

But also the fact that ALL the cgi parameters are passed to the Model causes the "Model" to become not truelly a view but to loose all interest, since it is only related to the current implementation of the web apps. On other words, that the "Model" keep model but loose its "comprehensiveness" ("Model" is not easily understandable).

I'm am quite new in project analysis, so please do not be too harsh. Why is this bad?

I have made a prototype with the main structures I have understood of this web application, made as short as possible.

#Model.pm
package Model;
import {
    # this requires an attribute called "view"
    # and this require an argument which is the cgi params
}
...

#View1.pm
package View1;
...

#Model1.pm
package ModelView1 ;
base Model;
use View1;

sub new {
    my $class = shift;
    my $arg   = shift;
    Model::DoSomething($arg);
    $self->view = new View1($arg);
    ...
}

#controller.cgi
my $model = 0;
...
     $model = new Model1( cgi_param => params() );
     #there is severall models here
...
print $model->get_view()->get_html();
  • 3
    since the object "Model" depends upon the "view" This is wrong. View should depend on model, not other way around. – Euphoric Aug 21 '14 at 14:37
6

Consider the model being just data. It doesn't make choices, and it doesn't know how to render.

  • A product can be a model.
  • A list of products can be a model.
  • A bundle containing the list of products, the cart and the information about the current user is a model.

The last model from the list corresponds to the data you need to render the page, but it shouldn't know how to render itself, because it's not the task of the model.

In order to render it, a view is used, given that the controller may pick different views depending on the context. It will use for example a view to render data to an ordinary guest visitor, a different view for an authenticated user, and a third view if the user is an administrator. Same data, different modes of displaying it.

  • Exactly. That's a good way of explaining it. As was said above, the Model has the data. The view displays the data. How does the data from the model get populated into the view? The controller takes care of that. – Cameron McKay Aug 21 '14 at 15:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.