SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 104
  1. #76
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the example McGruff, I'll study it more carefully later. It does look pretty interesting.

    Also, here's a code example for my previous post:

    The Front Controller could look like this:
    PHP Code:
    if (isset($_REQUEST['view']) && !isset($_REQUEST['command']))
    {
        
    $class $_REQUEST['view'] . 'View';
        if(
    class_exists($class))
            
    $view = new $class;
    }
    else if (isset(
    $_REQUEST['command']))
    {
        
    $class $_REQUEST['command'] . 'Command';
        if(
    class_exists($class))
        {
            
    $command = new $class;
            
    $view $command->view;
        }
        else
            
    $view = new ErrorView();
    }
    else
        
    $view = new DefaultView();

    $view->Render(); 
    Last edited by pakmannen; Aug 31, 2007 at 12:53.

  2. #77
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Hi pakmannen,
    You might want to take a look at the documentation for the Zend Framework. framework.zend.com

    Start with the Front Controller then work your way through the dispatcher and router till you get to the individual controllers. Many of your questions might get answered by looking at a fairly decent real life implementation.

  3. #78
    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
    We have to have clearly defined ideas so that we can communicate and so that we can analyse common problems effectively.
    The problem comes from not defining terms the same way. It's hard to communicate when we understand different things from the same words.

    Quote Originally Posted by McGruff View Post
    The reason to separate views and controllers is to isolate change. MVC allows you to change the view without also changing a controller. There aren't really any shades of grey: you either have to change controller code when you change a view or you don't. That prohibits controllers passing data - variables or "model" objects - to views since clearly you'll have to change the controller when the data displayed in a view changes.
    What your talking about is the separating UI from behavior, which isn't necessarily the same as view and controller. In my architecture, the code responsible for manipulating models is separate from the code responsible for displaying information to the user, but the latter includes controllers as well, they just not the same controllers that handle behavior. The controllers that handle behavior to their thing, then forward to another controller to display the results. Other web frameworks I've seen (rails, webobjects, struts) work in a similar manner.


    Quote Originally Posted by McGruff View Post
    That's not to say this is bad design. In a sense it's not design at all: the controller happens to have some domain objects lying around so they get chucked at the view simply because it's convenient rather than through any conscious choice.
    It's never a question of having domain objects lying around. The controller that is tied to a view exists solely for the purpose of providing that view with the model(s) it needs.

    Quote Originally Posted by McGruff View Post
    Still, if your controllers and views don't need to vary independently it doesn't doesn't matter if they are merged in a single presentation layer (just don't call that MVC).
    You are not the authority in what is or isn't MVC. You're equating view with presentation, which isn't the way MVC was conceived. A view in original MVC is a UI element like a textbox, which is bound to a model (which is any object that contains data, even a simple string), and either observes changes in the model, or is informed by the controller that the model has changed. In either case, the controller is what wires everything together, and that includes the actual binding of the view to the model. Take a look at apple's definition of controller:

    "Controller Objects Tie the Model to the View

    A controller object acts as the intermediary between the application's view objects and its model objects. Controllers are often in charge of making sure the views have access to the model objects they need to display and act as the conduit through which views learn about changes to the model. Controller objects can also perform set-up and coordinating tasks for an application and manage the life cycles of other objects."

    Also salient is this line regarding views: "Because model objects should not be tied to specific view objects, they need a generic way of indicating that they have changed."

    While I'm not terribly familiar with the original smalltalk implementation, In PoEAA, Fowler notes: "The second division, the separation of view and controller, is less important. Indeed, the irony is that almost every version of Smalltalk didn't actually make a view/controller separation."

    As for defining MVC in terms of web apps, the first two I'm aware of are WebObjects and Struts. Regarding controllers, the struts manual says:

    "For those of you familiar with MVC architecture, the ActionServlet represents the C - the controller. The job of the controller is to:
    * process user requests,
    * determine what the user is trying to achieve according to the request,
    * pull data from the model (if necessary) to be given to the appropriate view, and
    * select the proper view to respond to the user."

    and Webobjects:

    "Controllers act as the intermediary between the application’s view objects and its model objects. Typically controller objects have logic in them that is specific to an application. Controllers are often in charge of making sure the views have access to the model objects they need to display and often act as the conduit through which views learn about changes to models."

    All of which is to say is that, by any authoritative definition of MVC I have seen, the controller passes to model to the view. That doesn't mean that behavior is tied into UI, as there are other ways of addressing that.

    Quote Originally Posted by McGruff View Post
    If we use a refactoring app as an example, the domain action is to hunt through a filesystem, editing files. A controller will send messages to various domain objects to achieve this, but what about a view? There are all kinds of possibilities, eg:

    (1) one-liner: "operation succeeded/failed"
    (2) list every file which was edited
    (3) print diffs for every file which was edited
    (4) display the results of an "all tests" run using an app like SimpleTest

    In each case the domain action is exactly the same. If data were passed in to the view from a controller the controller has to be changed when the view details change. Separating controller and view would be useful if you want to support several view types. Maybe you're exploring a new domain and can't decide yet.
    The way I would implement this is to have one controller handle the domain actions, and redirect the user to another page, where a controller/view pair handles display. You can easily support several view types by redirecting the user to different controllers. This approach has an added advantage when to comes to web apps; since any action that modifies data should be behind a POST (or a PUT and DELETE if you're fully supporting REST), redirecting the user to a GET request afterwards means they won't re-submit the action if they refresh their browser.

  4. #79
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The controllers that handle behavior do their thing, then forward to another controller to display the results.
    Yes: once you strip out the domain action, all that's left is a view to create. The redirect is the view, really.

    Take a look at apple's definition of controlleR
    The Struts and Webobjects excerpts are wrong in my opinion.

    (Fowler) "The second division, the separation of view and controller, is less important. Indeed, the irony is that almost every version of Smalltalk didn't actually make a view/controller separation.
    Exactly. It appears to have been confused right from the word go. I think I share his sense of irony. You can find articles all over the web about MVC and all sorts of opinions. I think this is one of the better ones: http://www.phpwact.org/pattern/model_view_controller.

    You're equating view with presentation
    No. I'm trying to describe what it means to separate presentation (UI) into controller and view, how you can do that, and what indications there might be for doing this. That's the nuts and bolts of it. Who called what where doesn't really matter. Tightly coupled code means that changes can propagate throughout the design. To avoid that we need to identify different responsibilities and put them in the correct places. If I was faced with this for the first time, I'd literally be asking myself this question: should a controller gather viewable data used by the view to create a view. Which the user will then view.

    ???

    Views aren't just templates: responsibilities also include gathering data and possibly applying some kind of logic to that, before the final formatting and display.

    Maybe you can think of a controller as a fat general sitting on his horse, watching the battle from the top of a hill. He issues commands for guns to fire, horse to charge, and battalions to advance but he never gets his own hands dirty. He's looking at the big picture. He doesn't know, and doesn't need to know, the details.

    One should never design for the sake of design though. If you don't see a need to separate controller and view you shouldn't over-complicate things by adding unecessary requirements.

  5. #80
    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
    Yes: once you strip out the domain action, all that's left is a view to create. The redirect is the view, really.
    Which is my point; that even though we may define view and controller differently, the separation between domain actions and presentation is there.


    Quote Originally Posted by McGruff View Post
    The Struts and Webobjects excerpts are wrong in my opinion.
    Why should I believe you over apple and struts? Of course, you're entitled to your opinion, but there's a difference between an opinion and a fact, and the fact is that your opinion doesn't agree with two of the pioneering implementations of MVC in regards to the web, yet you insist that your definition is the "correct" one.

    Quote Originally Posted by McGruff View Post
    Exactly. It appears to have been confused right from the word go. I think I share his sense of irony. You can find articles all over the web about MVC and all sorts of opinions. I think this is one of the better ones: http://www.phpwact.org/pattern/model_view_controller.
    Yet even that one says "The view obtains data from the model and presents it to the user." I don't see the words "the view is responsible for selecting the right model" or anything to that effect.

    Quote Originally Posted by McGruff View Post
    No. I'm trying to describe what it means to separate presentation (UI) into controller and view, how you can do that, and what indications there might be for doing this. That's the nuts and bolts of it. Who called what where doesn't really matter. Tightly coupled code means that changes can propagate throughout the design. To avoid that we need to identify different responsibilities and put them in the correct places. If I was faced with this for the first time, I'd literally be asking myself this question: should a controller gather viewable data used by the view to create a view. Which the user will then view.
    Of course the controller gathers data, that's what it's job is. It decides what to display, the view decides how to display it. The controller tells the view "here, the user wanted to look at these articles" and the view displays them. Completely separate.

    As for coupling, you're not gaining anything by having the view select the model it needs, because you've reduced the coupling between the view and the controller by increasing the coupling between model and view, reducing the view's reuse. On top of that, since your view needs access to request information to decide what to view, you either need to couple your view to the request object, or have the controller pass that information thereby reincreasing the coupling between view and model.

    Or, you could just say that what you call a view is actually just a controller, and the part that simply displays the data is the view...

    Quote Originally Posted by McGruff View Post
    Views aren't just templates: responsibilities also include gathering data and possibly applying some kind of logic to that, before the final formatting and display.
    By your definition. I've NEVER seen any definition of MVC from any source I'd consider authoritative, where the view gathers data. Not one.

    Quote Originally Posted by McGruff View Post
    Maybe you can think of a controller as a fat general sitting on his horse, watching the battle from the top of a hill. He issues commands for guns to fire, horse to charge, and battalions to advance but he never gets his own hands dirty. He's looking at the big picture. He doesn't know, and doesn't need to know, the details.
    That sounds like a front controller to me. There are other controllers, like the guy operating the canon. The canon itself doesn't know what to fire at, and doesn't fire on it's own. It requires operators to feed it canon balls, and light the fuse.

    Quote Originally Posted by McGruff View Post
    One should never design for the sake of design though. If you don't see a need to separate controller and view you shouldn't over-complicate things by adding unecessary requirements.
    How about a code example... here's what you proposed earlier on:

    PHP Code:
    class MyController {
        function 
    __construct($model$assembler) {
            
    $this->_model $model;
            if (....)
                
    $this->_view $assembler->getUpdaterView();
            else
                
    $this->_view $assembler->getOtherView();
        }
        function 
    execute() {
            
    $this->_model->pressButton();
            
    $this->_model->pullLever();
            
    $this->_view->render();
        }
    }
    class 
    MyView {
        function 
    __construct($model$template) {
            ...
            ...
        }
        function 
    render() {
            ...
            ...
        }

    here's what I propose

    PHP Code:
    class EditingController {
        function 
    __construct($model$assembler) {
            
    $this->_model $model;
        }
        function 
    execute() {
            
    $this->_model->pressButton();
            
    $this->_model->pullLever();
            
            if (...)
                
    $this->redirect('updater_view');
            else
                
    $this->redirect('other_view');


        }
    }
    class 
    UpdaterViewController {
        function 
    __construct($model$template) {
            ...
            ...
        }
        function 
    execute() {
            ...
            
    $this->render($this->_template)
        }

    Fundamentally, the difference is mostly terminology, the seperation of concerns is almost identical. Incidently, in your example the view is getting the model from the assembler, which doesn't look like gathering data to me.

  6. #81
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > and the fact is that your opinion doesn't agree with two of the pioneering
    > implementations of MVC in regards to the web, yet you insist that your definition is the
    > "correct" one.

    I wonder just how much experience McGruff has with either of the Struts or WebObjects frameworks? To me, to actually have a point of view, you need to have a grounding on what that particular area of reference is, in this case two well known web based frameworks.

    I certainly couldn't have a point of view on something that I had no experience of; Hell, I just wouldn't have the hard neck to make a statement like that.

    Anyways, far be for me, a humble web developer to argue the point that these two frameworks are wrong, and that the teams of developers, who have spent a number of years working on them, got it all wrong.

    Lets not take into account the wealth of experience that those teams have, and what they brought to the respective projects, the blood, guts and tears they all shed to make something that benefits a lot of businesses today.

    Damn, this McGruff must know something huh? Something more than what the rest of us know huh? Must be great to know so much, so much more that those that spent a lifetime of learning to then go onto do something better, bigger, greater, and what?

    They got it wrong? Christ, this McGruff is good huh?

  7. #82
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,270
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    gentlemen, please

    i may not understand anything about what you guys are talking about, but i recognize animosity and thinly-veiled sarcasm

    please remember our rules, and show respect for each other

    thanks

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  8. #83
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why should I believe you over apple and struts?

    What sort of an argument is that? You might believe me because I might have taken the trouble to try to explain my thinking and because I might have made a convincing argument. Or I might not. If you're suggesting that the apple & struts developers cannot be questioned I'm obviously not going to agree with that. Nor would they, probably.

    For the record, I believe that authority belongs to those whose ideas survive peer review such as (I hope) we are engaged in here.

    Fundamentally, the difference is mostly terminology, the seperation of concerns is almost identical. Incidently, in your example the view is getting the model from the assembler, which doesn't look like gathering data to me.

    What it all boils down to is cutting out the middle man. A controller which passes data to the view knows more about the display than a controller which merely issues a render() command.

  9. #84
    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
    What sort of an argument is that? You might believe me because I might have taken the trouble to try to explain my thinking and because I might have made a convincing argument. Or I might not. If you're suggesting that the apple & struts developers cannot be questioned I'm obviously not going to agree with that. Nor would they, probably.
    I'm not saying they can't be questioned, but what you said is that they were wrong, and even if I completely agreed with your position, I could not in good faith say that theirs was wrong, because their very existance is part of what defines MVC (as it applies to the web, at least). You can interpret MVC as you wish, and you can disagree with other people's interpretations, but you cannot claim that you're right and they're wrong, unless you have some position of authority from which to say that.

    Quote Originally Posted by McGruff View Post
    What it all boils down to is cutting out the middle man. A controller which passes data to the view knows more about the display than a controller which merely issues a render() command.
    And a view that gathers its own data knows more about the request than a view that simply displays a model. You're making a tradeoff, and you're not even cutting out the middle man, you're just stuffing it inside the view.

  10. #85
    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 33degrees View Post
    You're making a tradeoff, and you're not even cutting out the middle man, you're just stuffing it inside the view.
    You've completely missed the point.

    Quote Originally Posted by 33degrees View Post
    you cannot claim that you're right and they're wrong, unless you have some position of authority from which to say that.
    Whom have you decided are the authorities? Is Jeff Moore an authority (the author of the WACT piece on MVC)? Personally I'm always interested to hear what he has to say although I wouldn't slavishly follow anybody. Why are you so obsessed with authority anyway? It comes across as a move to kill the discussion stone dead. I'd rather you tried to think for yourself: that's how people get to be authorities.

  11. #86
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I am going to attempt to comment on this with only reading the last couple of posts so bare that in mind.

    I think, that what is confusing to both of you is that you have opinions on how it should be done, but also have seen many different implementations. So, it can be struggling to determine the "right way to do it". The thing is though, there probably isn't. Frameworks are opinionated software, such that, their implementation is based on the opinions of their developers. When your building your own framework how much you take away, from others, is directly related you how much to respect and trust the authors.

    That all being said here is my opinion.

    I like to think of MVC as simply separating Application Logic, Business Logic and Presentation. Those are my basic "rules" to MVC as it were. The controller handles application logic, the model business logic and the view presentation.

    For some basic implementation. The model should not render the view because that would be application logic. The view should not pull the model or the controller, because again that is application logic. As all application logic should be in the controller. We can say that the controller should execute the business rules and render the view. I think anything else, violates the purpose of MVC.

    Now, how to formally structure the application logic in the controller is completely up to the programmer and, to me, as long as it ONLY contains application logic and both the model and view don't. Then, any implementation still encapsulates the problem MVC is designed to solve.
    So, if you want to have one controller which executes the model and a separate controller which renders the view, thats fine.

    I think when looking at other people's frameworks you can be tricked by the abstraction level of the controller. In Rails, for example, the controller, loads, sets, and executes the model and renders the view. But, behind the curtains. They, abstracted it to a library instead. Libraries in a MVC framework, to me, are tools for controllers and should only contain application logic as opposed to helpers which could do all three. Backing up a bit, the rails community talks about dumb controllers. Controllers which should only contain certain a level of abstraction. Such that, complex logic is refactored to libraries and what you see in the controller are just method calls for the most part. As opposed, to a lot of PHP frameworks, such as code igniter, which shows all the "glue" in the controller. Which makes it look drastically different from Rails even though to are doing the same thing. The only difference is the abstracted level of the controller the framework wants you to be working with.

    So, in closing. As long your properly separating Application logic, Business logic and Presentation. Then whatever your implementation you decide on is fine.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  12. #87
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Presentation is normally taken to mean the UI ie controller and view - not simply the view alone.

    I'd more or less agree with "whatever implementation you decide on is fine" except that, if you do need controllers and views to vary independently, they will need to be properly separated. There's not much more for me to say without repeating myself so I'm going to butt out.

  13. #88
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    > please remember our rules, and show respect for each other

    Sorry Rudy; But thousands of people come to Sitepoint, this forum in particular for help and advice, and us regulars just cannot have someone making a statement as such that was made, where they have no grounds to do so.

    People would therefore have the wrong impression if they were not to know better, but you are right. I should show greater understanding and patience, unfortunately at times it can be trying.

  14. #89
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,270
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    it's okay to be passionate about something

    whether you are trying to clarify or disagree, think about the discussion like a painting, a work of art, on a public easel so that everyone can contribute their brushstrokes to it, and if you want to clarify or disagree with something, do it to the painting itself, don't criticize anyone for their brushstrokes, or question their right to add them
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  15. #90
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sitepoint needs ideas. It needs people who like to explore ideas. There was a little bit of tension in this topic which I hoped would calm down. It can be difficult to discuss contradictory viewpoints but one hopes that everyone will eventually learn to trust each other enough not to take it personally.

    What matters is good faith. At worst, I am simply wrong. You (Dr Livingston) however have repeatedly tried to stir things up to further a personal grudge. That is not done in good faith, has nothing to do with the topic under discussion and is extremely destructive of the trust we need. If I was a moderator I would ban him.
    Last edited by McGruff; Sep 4, 2007 at 02:26. Reason: restored: please don't edit my posts

  16. #91
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been reading this excellent documentation of the Symfony framework recently: http://www.symfony-project.com/book/1_0. Thanks for the tip ahundiak. And my local library is sending for a copy of Martin Fowler's PoEAA.

    For the record, Symfony's Actions (commands) collect data from the Model and pass it on to the View. This is how they visualize "MVC":


    After reading the chapter on the Model, I suddenly understand a lot of what 33degrees was talking about earlier in this thread, about the passing of "models" to the view. And yes, it all came down to different interpretations of what a "model" is. The Model is, as far as I understand, a collective term for many different things. To call what I believe now to be an ActiveRecord a model will surely confuse people, such as me! Still not sure about all the terms such as Domain Logic and Data Access Objects but I'm getting there.

    ActiveRecord is actually what I'm working on at the moment, but I think I'll save that for a different thread. Though if anyone have useful links on the subject I'd be happy to see them.

  17. #92
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's one which might have got lost in the crossfire: http://www.phpwact.org/pattern/model_view_controller

  18. #93
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by McGruff View Post
    Presentation is normally taken to mean the UI ie controller and view - not simply the view alone.

    I'd more or less agree with "whatever implementation you decide on is fine" except that, if you do need controllers and views to vary independently, they will need to be properly separated. There's not much more for me to say without repeating myself so I'm going to butt out.
    If, I'm reading you right, you agree that the controller and view should be separate? In which case I agree. To me the presentation does not include the controller.

    One can think of it as a Power Point presentation. What you see on the screen is the presentation. What renders the presentation is Power Point. The controller.

    I think some of this trouble arises from using other patterns and injecting them into MVC.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  19. #94
    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
    You've completely missed the point.
    And you've completely missed mine.

    Quote Originally Posted by McGruff View Post
    Whom have you decided are the authorities? Is Jeff Moore an authority (the author of the WACT piece on MVC)? Personally I'm always interested to hear what he has to say although I wouldn't slavishly follow anybody. Why are you so obsessed with authority anyway? It comes across as a move to kill the discussion stone dead. I'd rather you tried to think for yourself: that's how people get to be authorities.
    I brought up the point of authority because you stated that your view of MVC is right and other peoples (apples and struts) was wrong, thereby implying that you somehow knew better than them, thereby implying that you are an authority on the subject. You're the one who is stifling discussion by stating your opinions as facts, and insisting that people who don't share your viewpoint are somehow wrong.

    Quote Originally Posted by McGruff View Post
    I'd more or less agree with "whatever implementation you decide on is fine" except that, if you do need controllers and views to vary independently, they will need to be properly separated.
    Nobody's arguing that. The issue is simply "what is a controller" and "what is a view". There are several ways you can split the two and have them be completely separate, thereby varying independently.

  20. #95
    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 33degrees View Post
    I brought up the point of authority because you stated that your view of MVC is right and other peoples (apples and struts) was wrong, thereby implying that you somehow knew better than them, thereby implying that you are an authority on the subject.
    That's a rather nasty little trick you're trying to pull. I never claimed to be an authority. I can't: that's something which is given by other people as I mentioned earlier - peer review. You can keep posting about this all day long but the fact remains I am free to say whatever I like provided I can back it up. So is anyone else. That's called debate and it's how we learn.

    Could we agree to make further posts only in responses to the original poster, pakmannen? This is getting a bit ridiculous.

  21. #96
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What's a Controller anyway? Tries to clear up some of the confusion surrounding the Controller and identify the origin of the confusion.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  22. #97
    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
    That's a rather nasty little trick you're trying to pull. I never claimed to be an authority.
    I'm not trying to pull tricks, and I apologize if that's the impression I'm giving. I just find it frustrating to come up with examples that support my point of view, and then being told that those examples are wrong. That's the kind of thing that makes discussions degenerate.

    Ultimately, the point that I want to make is this: each of the tiers of MVC consists of many parts, and while some parts parts fit neatly into a given tier, the ones at the boundaries between tiers are less obvious. I consider loading a model to display is one of those parts; there are valid reasons for putting it in either tier, and ultimately what tier it belongs in is less important than making sure it's as decoupled as possible from the parts surrounding it.

  23. #98
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks. Maybe I didn't put enough "in my opinions" in.

    Were we arguing about something? I've forgotten already

  24. #99
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Something I've thought about a bit..

    When sorting stuff into "modules" do you make, say, a folder for each module and make one php file per action, each file containing an execute() method, OR, do you make one php file per module and make each action a method?

    In other words, do you make actions classes or methods?
    PHP Code:
    $action->execute(); // One action per file
    $module->$action(); // One module per file 
    With one action per file you obviously get smaller files, and you can work on one action without breaking the others in that module. With one module per file you get the ability to call a method from another method within the same module, and less folders/files. What's the better way here?
    Last edited by pakmannen; Sep 5, 2007 at 04:45.

  25. #100
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pakmannen View Post
    What's the better way here?
    Well, 'better' is highly subjective
    I prefer to define related actions as controller methods. In my experience this way of code organisation makes it easier to quickly grasp what's going on in a specific part of a site or application because the controller class provides an 'overview'. It makes sharing logic a little easier too.
    With complex applications I've noticed that controller classes tend to become rather fat. This can usually be fixed with a little refactoring however, like moving data access logic to models.


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
  •