SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 57
  1. #26
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I jave been designing for some time now - in PHP for 3 years - and I have come to the conclusion that Views should NOT EVER directly manipulate a Controler. Views should only reference controlers ala Hyperlink.

    The reason I've come to this conclusion is because a view is simply a portal or a window BUILT FROM the processed buisness logic. The view simply enables the viewer (individual) to more easily digest the raw information from the model. It also serves to organize information from the model in the most efficient mannor which is referenced via the controler/s.

    Having worked on my own CMS I initially didn;t know much about book (fowler) logic patterns, I simply worked out the logic myself and did all the MATH by hand until I devised a working patern that now has what people call controlers, views and a model (or models) - though it is NOT a MVC model.

    Thanks to many people here (you guys and gals know who you are), I've been reading up on MVC and the like the past year - I just don;t agree with it. I think it's too simple to really solve the problems presented by internet style application elegantly - it's cutting cornors for sake of simplicity.

    I could be incorrect, but in the limited experience I have, a View should be the end of the line when it come to logic and anything that happens there should not ever effect the buisness code/process whatsoever.


    IS this logical to you?

    Interesting post,
    Cheers
    Last edited by Resolution; Nov 11, 2003 at 19:31. Reason: Expounded on some ideas

  2. #27
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I took a look at the post from SIllysoft (thanks) and I see it does in fact say some of the things I stated. I'm still holding to the perception that MVC (or should it be VCM?) is very much simplified in its attempt to explain a workable pattern but, I can see its a good start for anyone who's willing to put in the work and extract the LOGIC that's going to fit thier application.

    cheers


    PS: An interesting example http://www.geocities.com/pbanta/Mode...ontroller.html
    Last edited by Resolution; Nov 11, 2003 at 21:13.

  3. #28
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Finland
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Exactly Martin Fowler seriously recommends this approach btw.

    Absolutely nothing wrong with this at all actually
    I still have the check the data patterns from Fowler's P of EAA more carefully, but for now I would disagree that there is a class for each table in the database. I have in all of my projects had many-to-many relationships, which require a special linking table with just a paired primary key, one id from the first table and another from the second table.

    One case being for example a user that belongs to multiple groups and a group having multiple users in it. This requires three tables but probably only translates into two model classes, User and Group.

    SamuliK

  4. #29
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Made an attempt at demonstrating the simplest possible MVC example in PHP I could imagine here (pages 9, 10 and 11 are the complete example). May be helps explain what MVC is about.

  5. #30
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation Where is the view!?

    I was working on a long rant, but decided I could save a bunch of time by just asking one question:

    Would you not agree that for the vast majority of web applications (i.e. PHP scripts), the View layer is represented by the client's browser?

    It seems to me that most of the problems people are having with the MVC pattern on these forums are caused by trying to squeeze the entire pattern into their application, when in reality they only need a Controller, a Model layer, and an ResultMessage class (template class).

  6. #31
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Azmo, to some extent, I agree. In the "Industrial Strength MVC" article I wrote for PHP|A I include a figure of the "application stack" in which the template class, resulting HTML and the browser were the "view" portion of the MVC.

  7. #32
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You may find that you do not need in most cases a MODEL for a VIEW in relation to a FORM though by all means you still need the CONTROLLER which controls what the user inputs, ie validation, error trapping etc etc.

    As to the point of needing either one main controller or one each per action passed via $_GET then I choose to have one each per action rather than for example one controller using SWITCH to seperate each given action.

    Reading some stuff a while back [Thinking In Java I think ?] it was suggested that using SWITCH was a bad idea to base a CONTROLLER on, though why this is so, it wasn't exactly explained

    Would be interesting to know why the author stated this though...

  8. #33
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    View layer is represented by the client's browser?
    Nope. You do not only just have web browser's now. You have Web Tv ? PDAs ? Mobiles ? etc etc

    Are you now saying they all represent the VIEW Layer as well ? That's just being silly imo

  9. #34
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    Made an attempt at demonstrating the simplest possible MVC example in PHP I could imagine here (pages 9, 10 and 11 are the complete example). May be helps explain what MVC is about.
    Thanks Harry! It does help me understand better. But I had a question on the tutorial on PHP Patterns. MVC 2 the index.php would be the controller correct? You had a switch in there that deteremined which controller class to run. Is that correct? Meaning are you using the controller to determine which controller to run?

    PHP Code:
    $dao=& new DataAccess ('localhost','','','');
    switch ( 
    $_GET['view'] ) {
    case 
    "product":
    $controller=& new ProductItemController($dao,$_GET);
    break;
    default:
    $controller=& new ProductTableController($dao,$_GET);
    break;
     
    }
     
    $view=$controller->getView();
    echo (
    "<pre>" );
    // print_r($controller);
    echo ("</pre>" );
    echo (
    $view->display()); 
    Silly

  10. #35
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That is one way of doing this though I prefer what is known as mapping ?

    Still working on this though myself Btw good article Harry...

    [Off Topic] Any news on your forthcoming Site Point book ? [/Off Topic]

  11. #36
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But I had a question on the tutorial on PHP Patterns. MVC 2 the index.php would be the controller correct? You had a switch in there that deteremined which controller class to run. Is that correct?
    Yep - in fact that switch which selects a specific controller might be called a front controller. Whether I'd actually do things that way in practice is another question. You may well want to read what's going on in this thread

  12. #37
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    Yep - in fact that switch which selects a specific controller might be called a front controller. Whether I'd actually do things that way in practice is another question. You may well want to read what's going on in this thread
    Another question. Can view be in the controller? Meaning if you have index.php, which is the controller, does the view need to be in a class or can you put html in index.php? Or to build parts of the site do you have multiple view classes? Say to build a header, then a menu, then a second view to get the dynamic info

    Silly

  13. #38
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wouldn't put the View Layer inside the Controller Layer as this breaks the whole purpose of MVC...

    As to this wee bit
    Say to build a header, then a menu, then a second view to get the dynamic info
    I would suggest that you look at the Pattern Template Method at WACT ?

    I previously posted the sample script [from WACT] in a thread recently so you may want to have a look back over the last 3 weeks on all posts I've posted to in this period ?

    This deals with what your asking from the QUOTE I give me thinks

  14. #39
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    I wouldn't put the View Layer inside the Controller Layer as this breaks the whole purpose of MVC...

    As to this wee bit I would suggest that you look at the Pattern Template Method at WACT ?

    I previously posted the sample script [from WACT] in a thread recently so you may want to have a look back over the last 3 weeks on all posts I've posted to in this period ?

    This deals with what your asking from the QUOTE I give me thinks
    So using MVC what do people normally do when creating a webpage? Follow a design pattern and then a template pattern?

    Silly

  15. #40
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sillysoft
    So using MVC what do people normally do when creating a webpage? Follow a design pattern and then a template pattern?

    Silly
    I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

    HTH

  16. #41
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

    HTH
    Yeah that is what I been doing since starting this thread. I just kept thinking there is one view. So is it safe to say that for each view you create there will be a model for it? (If dealing with a db) So for instance you create the foundation in the view class then have a model/view class to say build a dynamic menu, then another view and model class to create, say a list of items in another section of the page?

    Silly

  17. #42
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Nope. You do not only just have web browser's now. You have Web Tv ? PDAs ? Mobiles ? etc etc

    Are you now saying they all represent the VIEW Layer as well ? That's just being silly imo
    Then please explain how these are different from the web-application's point of view... they all send requests to the application using http, process the resulting document (either XML or one of its subtypes, like HTML), and render it on a display.

    The reason I'm saying that the View layer should not be part of a web-application is this: web-applications don't have a user interface the way normal applications do. In normal applications the user interface is an integral part of the application, whereas web-applications rely on remote platforms to process and render XML or HTML documents into a user interface. In normal applications the controller waits for user input (like mouse clicks, and key presses). Web applications don't. They simply process any incoming request, and return whatever [X/HT]ML document is the result of that request.

    The browser on the other hand does wait for the user's input. If he clicks on a link, a new request is sent to a webserver; if values are entered into form elements, the View is updated. When the submit button is pressed, all the values of the form are combined into a single request, and again sent to a webserver. This makes the browser slightly more than just the View: it also has some logic to interpret the various document types, and it can handle user input for forms etc. all by itself.

    In short, I'd say that MVC in web-applications looks something like this:

    - View == webbrowser (or any other platform that renders XML)
    - Controller == webserver (+ web-application's controller)
    - Model == web-application

    The View and Controller communicate using http, the incoming message on the webserver contains the requested action and its parameters, the outgoing message contains the new document to be rendered in the View.

    Still sounding silly?

  18. #43
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Azmo, MVC is simpler than that:

    Controller = Input
    Model = Processing
    View = Output

    MVC has experienced a revival in web development because in a web application the distinction between input and output, between request and response, is so well defined as opposed to most GUI applications.

    From Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC)
    In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
    Translated to the web application: The controller is responsible for Request handling. The view is responsible for Response handling. The model is the logic or processing of the application; the function it provides.

    So some theoretical separation of concerns:
    • Only the controller can use the PHP request handling functions.
    • Only the view can use the PHP response handling functions.
    • The model should not directly call either the view or the controller. It can indirectly call the view via events -- see dependency inversion principle (PDF).
    • The view should not directly call the controller.
    • The view can access the model for informational purposes, but should not attempt to make state changes.
    • The controller has access to both the view and the model.

    To confuse things, there is another pattern called Presentation, Abstraction and Control. This is similiar to Ivar Jacobson's Interface objects, entity objects and control objects in OOSE which introduced use cases evolved into the Rational Unified Process. This divides responsibilities slightly differently:

    Presentation - Both Input & Output
    Abstraction - Information
    Control - Behavior

    From OOSE:
    The control objects typically act as glue which unites the other objects so they form one use case.
    ...
    Typical types of functionality placed in the control objects are transaction-related behavior or control sequences specific to one or a few use cases.

  19. #44
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    Brisbane, QLD
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    great explanation selkirk!

  20. #45
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From the Pragmatic Programmers:
    A Pattern is a relatively new idea in computer science. It attempts to document a solution to a problem in a given context.
    Here's the problem I have with MVC in web-applications: the pattern has been taken out of its original context (complete real-time application with its own user interface), and has been redefined in a new context (web-applications, relying on a separate webserver and remote client). Not only do you end up with two rather different descriptions of the 'same' pattern, but each description is also invalid for the other context. I can understand why so many people are confused about MVC after reading about it on the internet (I sure was at first); there are two distinctly different patterns out there using the same name...

    A normal application based on MVC should be fully capable of being executed without help from external programs, right? The Model, View, and Controller can take care of every aspect of the application. But how does a PHP script based on MVC fare without the webserver or the webbrowser? We've already accepted the fact that the webserver can be the (Front) Controller, why is it impossible that the webbrowser is the View?

    And I'm asking this from the perspective of the original MVC pattern, not the anti-pattern version used by many webdevelopers.

  21. #46
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Silly ? Not picking an argument folks though I still think that a web browser does not represent the View layer, likewise a web server does not represent the Controller layer, as suggested in another thread by HarryF

  22. #47
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by The Pragmatic Programmer
    While MVC is typically taught in the context of GUI development, it is really a general-purpose programming technique. The view is an interpreetation of the model (perhaps a subset) -- It doesn't need to be graphical. The controller is more of a coordination mechanism, and doesn't have to be related to any sort of input device.
    • model The abstract data model representing the target object. The model has no direct knowledge of any views or controllers.
    • View A way to interpret the model. It subscribes to changes in the model and logical events from the controller.
    • Controller A way to control the view and provide the model with new data. It publishes events to both the model and the view.
    I think this book is getting a bit dated regarding MVC. I think most people today learn MVC as a result of web development, not GUI development. The books treatment of MVC is very GUI oriented.

    The HTTP protocol's strict sequencing of input and output has revived the original small talk definition of MVC where the controller handles input.

    Quote Originally Posted by The pragmatic Programmer
    The View and controller are tightly coupled, and in some implementations of MVC the view and the controller are a single component.
    Rewrite this sentence with an input/output viewpoint:

    The output and input are tightly coupled, and in some implementations the output and input are a single component.
    This is a very PAC-oriented viewpoint and probably true in GUI development. Presentation components handle BOTH input and output. However, in the web world, the input and output are not as tightly coupled, as the HTTP protocol distinctly divides them.

    Quote Originally Posted by Azmo
    Here's the problem I have with MVC in web-applications: the pattern has been taken out of its original context (complete real-time application with its own user interface), and has been redefined in a new context (web-applications, relying on a separate webserver and remote client).
    It works well in a web context. Perhaps better than it did in the GUI context.

    Quote Originally Posted by Azmo
    Not only do you end up with two rather different descriptions of the 'same' pattern, but each description is also invalid for the other context. I can understand why so many people are confused about MVC after reading about it on the internet (I sure was at first); there are two distinctly different patterns out there using the same name...
    Yes, but the web-MVC of the 2000's is the SAME as the smalltalk GUI-MVC of the 1980's. Its the GUI-oriented MVC of the 1990's that went in a different direction. ( A time, I might add, where you were considered an OO programmer if you knew how to drag a pre-made component from a palette to a window in an IDE. )

    The point of MVC is to separate things that change at different times for different reasons. The model changes based on business requirements. The view changes based on output requirements. The controller changes based on input requirements.

    In practice, PHP is a special purpose language designed for web applications. This has nothing to do with the MVC pattern.

    Here is Martin Fowler's take on this:
    Quote Originally Posted by Patterns of Enterprise Architecture
    The fact that most GUI frameworks combine view and controller has led to many misquotations of MVC. The model and the view are obvious, but where's the controller? The common idea is that it sits between the model and the view, as in the Application Controller (pattern) -- it doesn't help that the word "controller" is used in both contexts. Whatever the merits of an Application Controller, it's a very different beast from an MVC controller.

  23. #48
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The view changes based on output requirements.
    Exactly as to why I do not see the web browser acting as the View layer; It is the web page that acts as the UI and not the browser, which only implements what the server sends to it

    Anyways, this is proberly off topic but I'm currently reading this article at the moment - the reason I've come back to this thread after leaving it for the day

    Enjoy.

    http://www-106.ibm.com/developerwork.../j-oobuilding/

  24. #49
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

    HTH
    So I just wanted to verify. Is it safe to say that you could have a model for each view? Meaning could a web page template be made up of multiple views with models? For instance one view/model creates the header/footer, while another view/model creates a menu and then another view/model that creates the dynamic information in the middle?

    Silly

  25. #50
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sillysoft
    So I just wanted to verify. Is it safe to say that you could have a model for each view? Meaning could a web page template be made up of multiple views with models? For instance one view/model creates the header/footer, while another view/model creates a menu and then another view/model that creates the dynamic information in the middle?

    Silly
    The relationship is really many to many, i.e. a view could use one or none or many models, and a particular model could by used more than one view.


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
  •