SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42
  1. #26
    SitePoint Enthusiast
    Join Date
    Jan 2003
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I am going to echo the last several posts by saying this. If you think that frameworks are cramping your style, if you think that frameworks are limiting your skills and increasing your overhead, the way you are defining "framework" is clearly wrong.

    As Captain Proton put it, a framework is simply a flow model for your application, or structure. Any models should fit in that framework just fine since the framework doesn't not have anything to do with the actual implementation. They force you to think about your application in an organized manner. In fact, a program designed in one language should be easily converted to another language using the same framework. In fact, different parts could be different languages.

    I truly believe that the MVC design pattern is one of a few definite solutions to the web application environment.

  2. #27
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, except that MVC on the web is not that clearly defined.

    The responsibilities of the M, V and C in a desktop application make perfect sense:
    - M: represents some part of the application's (persistent) state
    - V: windows that retrieve information from that model and draw widgets
    - C: reacts to mouse clicks, drag & drops, etc, i.e. user input

    There is no such type of Controller in a web application: it's not PHP's responsibility to respond to mouse clicks or drag & drop.

    Some people seem to regard MVC in web applications as a combination of 1) A database, possibly DataObjects (Model), 2) HTML templates / XSLT stylesheets (View) and 3) Code that loads from the Model and sets up a template engine (3rd party or just PHP) or the XSLT processor (Controller). I think that Controller and View in the above definition form the View together, because they both 'present' the Model to the outside world. The Controller in a MVC web application should respond to user input such as submitted form values, which makes its purpose closer to the traditional controller of a desktop MVC application.

    Struts and Phrame, the latter of which is a port to PHP of the former, implement the MVC pattern in a much better way, IMHO

  3. #28
    SitePoint Enthusiast
    Join Date
    Jan 2003
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Struts and Phrame, the latter of which is a port to PHP of the former, implement the MVC pattern in a much better way, IMHO
    Which is why I am using Struts on this next project and currently working on a port to PHP (which covers a bit more ground than phrame) called Studs. So far, I love what I see. The one thing I don't like about Struts is the taglib library. I would much rather use PHP templates, hence the desire to want to make one in PHP. I will probably not be sure for quite a while which language I like better, Java because of its more formal nature, or PHP because of its more convienent, friendlier nature. Who says I even have to choose?

  4. #29
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The responsibilities of the M, V and C in a desktop application make perfect sense:
    - M: represents some part of the application's (persistent) state
    - V: windows that retrieve information from that model and draw widgets
    - C: reacts to mouse clicks, drag & drops, etc, i.e. user input
    This is not the general definition of MVC for desktop applications. Maybe to you it makes perfect sense, but this is the first time I've seen this definition used... In short: the controller has nothing to do with reacting to user input.

    Also, a View never retrieves information from the Model directly. That's what the Controller is for. A single controller can be connected to many views, and many models. The views know nothing about the models, and models nothing about the views.

    Vincent

  5. #30
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I admit I wrote that definition down too quickly, I'm sure it won't be 100% correct. But:
    In short: the controller has nothing to do with reacting to user input.
    From the website http://ootips.org/mvc-pattern.html, and I'm sure many others will say something similar:
    A controller is the means by which the user interacts with the application. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button or chooses a menu item, the controller is responsible for determining how the application should respond.
    ALso:
    Also, a View never retrieves information from the Model directly. That's what the Controller is for.
    . That depends on how you view it, I guess. If you mean that a View should not for example make a database connection and retrieve model data from there, you're right. But the View needs to have access to model data in one way or the other, otherwise it cannot display it. A Controller should pass the Model to the View where the View can display data from that Model. Model is something that I have not seen a clear definition of yet either.

    The views know nothing about the models, and models nothing about the views.
    Sometimes, Models are loosely coupled to a View, via an Observer relation. And I think a View has to know about the Model through some sort of interface.

    Please correct me if I'm wrong of course, I'm eager to learn.

  6. #31
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Apologies for not replying any sooner; I've been busy.

    Quote Originally Posted by Captain Proton
    I admit I wrote that definition down too quickly, I'm sure it won't be 100% correct. But: From the website http://ootips.org/mvc-pattern.html, and I'm sure many others will say something similar.
    Okay, I said things a bit wrong:

    In short: the controller has nothing to do with reacting to user input.
    What I meant was: a user normally influences a view directly (by clicking the mouse and so on), so in that sense the controller has nothing to do with it. On the other hand, the view directly passes on the effect of what user input on that view should do on to the controller. (Clicking a button in one view may have a different effect than clicking a button with the same label in another view; the views make care the right command is passed on to the controller.)

    A Controller should pass the Model to the View where the View can display data from that Model. Model is something that I have not seen a clear definition of yet either.

    Sometimes, Models are loosely coupled to a View, via an Observer relation. And I think a View has to know about the Model through some sort of interface.
    You admit you don't fully understand what a Model is. This is justified by you saying that a View may, in fact, access a Model directly. This is horribly incorrect. I say 'horribly' because accessing a model from a view directly negates the whole idea of the MVC concept.

    So what is a model? It's just a bunch of data somewhere. The traditional example is a spreadsheet. The model contains the data in the spreadsheet, and the view is responsible for displaying it. This can be in a simple tabular format, or it can be in a graphical form, like a pie chart.

    You are correct in saying that if a view wants to present data (from a model), then it has to access that data. (Duh! ) But it should always do so through the controller. This separation of view and model allows the model to be replaced without affecting any of the many views on the same model. Imagine going from a flat file system to a relational database system. By putting the code necessary to obtain and update data in a single controller, no view has to be updated (as long as the interface of the controller stays the same).

    Controllers are often implemented as Observers, and Views as Observables. Whenever a view changes, the controller is notified, after which all other views are notified instantly. This allows you to change the tabular data and the pie chart both at the same time.

    I must say that the definition I use here for MVC is the one from Smalltalk (as covered by the Design Patterns book). There is another definition, sadly also called MVC, that works different. That's the one ootips.org is talking about...

    Vincent

  7. #32
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by voostind
    You are correct in saying that if a view wants to present data (from a model), then it has to access that data. (Duh! ) But it should always do so through the controller. This separation of view and model allows the model to be replaced without affecting any of the many views on the same model.
    I'm curious how this relation is implemented. Does the View call a method like getModel() on the Controller, or does its constructor accept a model object that is only known through an interface (so the source of the model data can be varied)? If that's the case, I don't think our definitions are that different.

    When I said a View may access a model directly, I meant what I said above. The View knows about the model through some interface. The object that is passed to the View can come from any data source, as long as it implements the interface known by the View.

    So, 'interface' is the keyword here

  8. #33
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I'm curious how this relation is implemented. Does the View call a method like getModel() on the Controller, or does its constructor accept a model object that is only known through an interface (so the source of the model data can be varied)? If that's the case, I don't think our definitions are that different.
    Not quite

    The view calls methods directly on the controller. So when there's a controller for a model storing tabular data, the view can tell the controller to change the cell at position D9, for example. The controller then takes care the model is updated. This may seem a little bit stupid, but take into account that:
    - The controller can use smart caching techniques, only updating a (possibly hard to reach) model every so often.
    - The controller presents only a subset of the interface of the model to the view. So if a view has a controller attached that has only get-methods, it simply cannot change any data, even if the model can.
    - In most MVC applications there is 1 controller, but this needn't be so. There can be many controllers on top of the same model, for many different views.

    Again, it's all about indirection.

    Vincent

  9. #34
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Again, it's all about indirection.
    Weren't you the one that said too many indirections were a bad thing?

    To me some of what you are saying does not make much sense, but that is probably because i don't really understand MVC that well yet. It makes perfect sense that a View should not call methods on the Model that alter the state of that Model, such as set*() or save() methods. Manipulating the model is the responsibility of the controller of course.

    In a web application with, for example's sake, HTML Views, a View never updates the Model, it only presents it, so that is not really an issue.

    What does not make sense to me is that a controller must provide accessor methods to the View, so the View can access data from the Model. Assume you have a Model object with getPropertyX() and getPropertyY() methods, does it make sense to duplicate those methods on a Controller class? To me it seems more logical that the View accepts an object that it only knows through an interface with accessor methods, i.e. getPropertyX() and getPropertyY().

    Would you care to clarify this? I'm really interested

  10. #35
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    What does not make sense to me is that a controller must provide accessor methods to the View, so the View can access data from the Model. Assume you have a Model object with getPropertyX() and getPropertyY() methods, does it make sense to duplicate those methods on a Controller class? To me it seems more logical that the View accepts an object that it only knows through an interface with accessor methods, i.e. getPropertyX() and getPropertyY().
    If you view it like this, then indeed it doesn't make much sense. In my previous post I described a controller as an object that copies (part of) the interface of a model, so that the view can use it. The benefit of this is that if the model changes, only the controller needs to be updated. The controller can keep the exact same interface, although the implementations may be a bit more complicated than before.

    Also, controllers can give views an interface that doesn't look like the model's interface at all. Why would you want to do that? How about one view, that can be used by 6 different models? The controller can be used to offer a unified interface to the view.

    Finally, the number of set- and get- methods in a controller is typically not that large. The methods will not be that fine-grained, getting and setting large chunks of data from the model at once.

    Anyway, as I said before, there are different patterns that are all called MVC, so that makes talking about it a bit difficult.

    Vincent

  11. #36
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by voostind
    Also, a View never retrieves information from the Model directly. ... The views know nothing about the models, and models nothing about the views.
    Quote Originally Posted by voostind
    I must say that the definition I use here for MVC is the one from Smalltalk (as covered by the Design Patterns book).
    Huh?!?

    From Design Patterns chapter 1.2: Design Patterns in Smalltalk MVC:
    The model communicates with its views when its values change, and the views communicate with the model to access these values.
    The model to view communication can be done indirectly using an observer pattern.

    The view to model communication can be done directly for accessing the state of the model.

    The model should not communicate with the controller.

    The controller communicates with the model by mapping input into commands which act upon the model, changing its state. (perhaps even using the command pattern)

    In traditional smalltalk MVC, the view and the controller are allowed to freely communicate with each other.

  12. #37
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have the DP book as well, that's why I found what Vincent wrote so strange at first. If there is such a thing as an 'official' definition of MVC, it's gotta be the one in the Design Patterns book, even though that book is a bit vague about it.

  13. #38
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Huh?!? From Design Patterns chapter 1.2: Design Patterns in Smalltalk MVC
    You're both very right. I've been following this thread in the few spare moments I've had lately, and haven't checked my resources as sufficiently as I should have. My apologies for that.

    As I still won't have a lot of time on my hands for the time to come, I'll refrain from making any more posts in this thread and will stop making a complete idiot out of myself, throwing the little reputation I had overboard

    Vincent

  14. #39
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, the points you made, such as the one about one controller/view being able to support various models, make sense, but I think there are other better methods to implement this. For models with different interfaces, the Adapter pattern could be useful.

    ... the little reputation I had...

  15. #40
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yet, its taken until PHP 5 to get a decent object model for the language.
    I'm not sure if you remember, but the REAL object model isn't even going to be implemented until version 5. They just put in a really weak one BARELY in PHP 3. PHP 2 was weak all around, and PHP/FI (1) was just some tools so Rasmus could keep track of hits on his resume. So, I think that from where the Object Model started, it has come farther that ANYONE expected that it would when it first started. I mean, hey, look at perl... Where is there object model?
    Ryan

  16. #41
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oops, I didn't realize that there was still a whole 'nother page of posts before the end. I believe the quote above was from like the third post on the first page, or something. =)
    Ryan

  17. #42
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In the long run of application development, yes it is a got thing.

    You may want to develop application 'xyz' which does '123' and requires functionality such as 'abc'.

    In most instances you'll already have incoporated functionality 'abc' into your framework and thus to use it in your new funky cool application 'xyz' all you'd need to do then is 'reference' it or get a 'handler' of the functionality.

    Most people, myself included use OOP for frameworks and this in it's self simplifies development and how someone can actually use the framework; even someone who has no say in it's development.


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
  •