SitePoint Sponsor

User Tag List

Page 2 of 5 FirstFirst 12345 LastLast
Results 26 to 50 of 104
  1. #26
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    As far as I've seen, having the controller pass the Model to the View is the common accepted definition of the pattern ...
    The only way to have a full view/controller separation, is by letting the view select the model. The controller selects the view, but it shouldn't pass any model to the view.
    Of course, you may chose to have less separated view/controller layers. In many cases, this makes sense, since the further separation would just add bureaucracy. Calling it MVC is slightly misleading though.

  2. #27
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    Why pass the entire model object on to the view? The view should only need exactly the data it requires to render the view, is that not correct? The controller seems like the logical place to handle this.
    Because it's not the controller's responsibility to know exactly what information to display, beyond what it can infer from the user's input. By extracting the data in the controller, you increase the coupling between the controller and the view, which makes your application less flexible. The more information about the view the controller has, the more chances there are that changes to the view will mean changes to the controller, and supporting multiple views with the same controller becomes more complicated.

  3. #28
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    The only way to have a full view/controller separation, is by letting the view select the model. The controller selects the view, but it shouldn't pass any model to the view.
    That is valid opinion, but I disagree. A view is a visualization of the state of a model; having it decide which model to display increases it's responsibilities outside the realm of presentation, into analysis of the user's request, which is the controller's job. This is important because, just as a controller can share multiple views, multiple controllers can share the same view. I use generic views like this often; for example, an xml export view that can display the content of any model.

    Quote Originally Posted by kyberfabrikken View Post
    Of course, you may chose to have less separated view/controller layers. In many cases, this makes sense, since the further separation would just add bureaucracy. Calling it MVC is slightly misleading though.
    I don't think it's misleading, because it's a commonly accepted definition of MVC as it applies to web applications.

  4. #29
    SitePoint Addict
    Join Date
    Jun 2005
    Posts
    260
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    This is a bit ambiguous, but in his code examples he passes the model object itself to the view. As far as I've seen, having the controller pass the Model to the View is the common accepted definition of the pattern
    Let's say I had the following class:
    Code:
    class Users
    {
        function find_all()
        {
            // return database result set.
        }
    }
    Your controller implementation would pass the Users object directly to the view:
    Code:
    class Controller
    {
        function execute()
        {
            $users = new Users;
            $view->set('users', $users);
        }
    }
    instead of passing the data:
    Code:
    class Controller
    {
        function execute()
        {
            $users = new Users;
            $view->set('users', $users->find_all());
        }
    }
    For the first approach, the view would be responsible for calling the find_all() method?


    correction: had the code blocks in the wrong order. fixed.

  5. #30
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by champ View Post
    For the first approach, the view would be responsible for calling the find_all() method?
    No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view. Initially, I had my finder methods be static methods on the model class, but this eventually lead to a bunch of problems.

    I wouldn't have the view call find_all, because find_all can take parameters (like page number, or sort order), and it's the controller that handles that stuff.

  6. #31
    SitePoint Addict
    Join Date
    Jun 2005
    Posts
    260
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view.
    Just for clarification, you mean something like:
    Code:
    class User
    {
        public $id;
        public $email;
        public $username;
    }
    
    class Users
    {
        function find_by_id($id)
        {
            // Query the DB for a user record by id.
            // Convert the result set row into a User object.
            // Return User object, or false if nothing found.
        }
    }
    
    class Controller
    {
        function execute($id)
        {
            $users = new Users;
            $user  = $users->find_by_id($id);
            $view->set('user', $user);
        }
    }
    If that's the case, I have a feeling there may not actually be a disagreement in what you're suggesting. I think there's been confusion regarding how we're individually defining what is or isn't a Model.

  7. #32
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by champ View Post
    Just for clarification, you mean something like:
    Yes, that's what I mean. Confusion is an unfortunate reality when discussing topics like this

  8. #33
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Users is definitely a domain object.

    I'd strongly disagree with calling something MVC unless there is a genuine separation between controller and view. I don't like nuts in my ice cream.

    Views are free to read from domain objects and a view object should make the finder call.

  9. #34
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That nuts and ice-cream analogy is silly due to the line - "Guaranteed nut free. Only ten per cent nuts".

    No one is saying they have guaranteed a 100% separation of view and controller. It's a design pattern - there are multiple ways to skin a cat depending on the problem at hand.

  10. #35
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow, this is complicated stuff. I assumed that $user = new User() was the model object, but okey.. 33degrees, would this be "correct" then?
    PHP Code:
    class DisplayUser extends Controller
    {
        function 
    __construct()
        {
            
    $this->user = new User();
            
    $this->view = new View('displayuser');
            
    $this->view->user $this->user->DisplayUser($_GET['id'])
            
    $this->view->Output();
        }

    The controller is responsible for executing the model methods? For instance, when someone logs in, the Controller executes the login method before letting the View render the page?

  11. #36
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    The controller is responsible for executing the model methods?
    The controller is responsible for invoking modifications on the model (methods called set/append/save/store et cetera), the view is responsible for reading data from the model (usually getters or properties).
    Last edited by Jasper Bekkers; Aug 29, 2007 at 05:21. Reason: constructor -> controller
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  12. #37
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    This is important because, just as a controller can share multiple views, multiple controllers can share the same view. I use generic views like this often; for example, an xml export view that can display the content of any model.
    You can reuse view code in other ways than by letting the controller be middleman. Instead of having one component render the entire view, you can cut it into smaller blocks (helpers), which are model-agnostic. You can then have multiple views share the same helpers, but still leave it to each individual view to select the model. A common form of helper is a template. It's an extra layer of complexity, but that's exactly what MVC is about. You trade simplicity for decoupling.

  13. #38
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jasper Bekkers View Post
    The constructor is responsible for invoking modifications on the model (methods called set/append/save/store et cetera), the view is responsible for reading data from the model (usually getters or properties).
    So you would not agree with either:
    PHP Code:
    class Controller
    {
        function 
    execute($id)
        {
            
    $users = new Users;
            
    $user  $users->find_by_id($id);
            
    $view->set('user'$user);
        }

    nor
    PHP Code:
    class DisplayUser extends Controller
    {
        function 
    __construct()
        {
            
    $this->user = new User();
            
    $this->view = new View('displayuser');
            
    $this->view->user $this->user->DisplayUser($_GET['id'])
            
    $this->view->Output();
        }

    Since they are both controllers that "gets" data from the model?

  14. #39
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by shea View Post
    No one is saying they have guaranteed a 100% separation of view and controller. It's a design pattern - there are multiple ways to skin a cat depending on the problem at hand.
    If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.

    In practice MVC has come to mean whatever the individual says it means, and thus has become completely meaningless.The only way not to go mad is to treat it like a comedy sketch.

  15. #40
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So people disagree with Martin Fowler on this:
    The controller should determine which view should display the result and pass on the model information to it.
    The controller should NOT pass any model information to the View? It should only select the View?

  16. #41
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    So you would not agree with either:
    Since they are both controllers that "gets" data from the model?
    I would pass the $id to the view instead and let the view decide on what information it needs from the model.

    PHP Code:
    class Controller{
       public function 
    execute($id){
          if(
    $this->request->isPost()){
             
    $user $this->locator->get('User');
             
    $user->save(sanatize($this->request->form()));
          }
          
    $view = new View();
          
    $view->set('user_id'sanitize($id));
          
    $view->render();
       }
    }

    class 
    View{
       public function 
    render(){
          
    $user $this->locator->get('User');
          
    $userDataForDisplay $user->find_user_by_id($this->get('user_id'));
       }

    Quote Originally Posted by pakmannen View Post
    So people disagree with Martin Fowler on this:
    That depends on the definition of model information he is using. If $id could be considered model data I'm agreeing with him, if it means passing the actual model, or data fetched from the model I'm disagreeing.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  17. #42
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jasper Bekkers View Post
    I would pass the $id to the view instead and let the view decide on what information it needs from the model.

    PHP Code:
    class Controller{
       public function 
    execute($id){
          if(
    $this->request->isPost()){
             
    $user $this->locator->get('User');
             
    $user->save(sanatize($this->request->form()));
          }
          
    $view = new View();
          
    $view->set('user_id'sanitize($id));
          
    $view->render();
       }
    }

    class 
    View{
       public function 
    render(){
          
    $user $this->locator->get('User');
          
    $userDataForDisplay $user->find_user_by_id($this->get('user_id'));
       }

    Yes, that makes sense.
    That depends on the definition of model information he is using. If $id could be considered model data I'm agreeing with him, if it means passing the actual model, or data fetched from the model I'm disagreeing.
    Someone said he passes the actual model on to the view. But I see how you think here.

    Let's see, how about this:

    Model selection actually appears in both the Controller and the View, but for different reasons. The Controller only writes data to the Model (based on user input), while the View reads data. The View knows by itself which Model(s) to call; the Controller does not pass this information on to the View.

    Basically:
    1. The Controller checks user input.
    2. If anything is to be written to the Model, the Controller does this.
    3. The Controller creates a View (and sends along GET information such as $id)
    4. The View reads from the Model(s) it needs (when needed using the GET information)
    5. The View outputs the page.

  18. #43
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    Someone said he passes the actual model on to the view. But I see how you think here.
    That's how I used to do it, but it created more headaches than manageable when I wanted to add another model to the view.
    Basically:
    1. The Controller checks user input.
    2. If anything is to be written to the Model, the Controller does this.
    3. The Controller creates a View (and sends along GET information such as $id)
    4. The View reads from the Model(s) it needs (when needed using the GET information)
    5. The View outputs the page.
    6. The model can optionally inform both the controller and the view through an observer, but that's a rare case for web-applications.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  19. #44
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I put together a quick picture. Something like this then?

  20. #45
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.
    Sorry, but your analogies make no sense, although I do think I understand your position. The problem is simply that our definition of View differs. As far as I can tell, for you the View contains two parts; the first part finds the data to display, the second part actually does the displaying. In my view (pardon the pun), only the second part is actually a view, the first simply a specialized controller which is used in the context of displaying the page. So, you define what is a view based the context of the user request (editing data vs displaying it), I define view as simply the part that displays model information.

    There is a very strict separation of what is View and what is Controller in my case, I just don't draw the line at the same place.

  21. #46
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    664
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    I put together a quick picture. Something like this then?
    The line from the view back to the controller should read something like "Rendered output". The "User Input" (or Request) comes from the front controller to the controller usually via some sort of dispatcher.

  22. #47
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    664
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jasper Bekkers View Post
    I would pass the $id to the view instead and let the view decide on what information it needs from the model.
    I go one step further and turn MVC into MVCT where T stands for templates. The view class receives the $id and queries the model for user information. If the user is to be edited, the view might also query the model different information such as possible user roles and permissions. Whatever the html form might need.

    The view collects this information and passes it on to a template class for rendering. For different output formats, different templates would be chosen but still using the same information.

  23. #48
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view. Initially, I had my finder methods be static methods on the model class, but this eventually lead to a bunch of problems.

    I wouldn't have the view call find_all, because find_all can take parameters (like page number, or sort order), and it's the controller that handles that stuff.
    Quote Originally Posted by pakmannen View Post
    Wow, this is complicated stuff. I assumed that $user = new User() was the model object, but okey.. 33degrees, would this be "correct" then?
    ...
    You have been a bit misguided. The "model" is really only an ambiguous term that describes the data access layer. 33degrees is apparently using the RowDataGateway or ActiveRecord pattern to implement this, but it's certainly not the only way to do it. The term "model" has no real specific definition other than it must be the "data access" layer, so your implementation may very well be a valid "model".

  24. #49
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak View Post
    I go one step further and turn MVC into MVCT where T stands for templates. The view class receives the $id and queries the model for user information. If the user is to be edited, the view might also query the model different information such as possible user roles and permissions. Whatever the html form might need.

    The view collects this information and passes it on to a template class for rendering. For different output formats, different templates would be chosen but still using the same information.
    I'm also trying to create a template based solution. At the moment my "flow" sort of looks like this: FrontController -> "Command" -> View -> Template

    It feels like one of them is redundant. Should I really have to create three files (command, view, template) for each "new" page? I'm curious how you solved this. Is it possible to integrate the "Commands" into the FrontController or something?

  25. #50
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    The "model" is really only an ambiguous term that describes the data access layer.
    The model is another name for the domain layer not the data access layer.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •