SitePoint Sponsor

User Tag List

Page 2 of 6 FirstFirst 123456 LastLast
Results 26 to 50 of 142
  1. #26
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    In the enterprise I would have the controller select the view and know nothing at all about the domain. I see no reason for the controller to see the domain as the domain here is likely to be exceedingly complex.
    But this way, you have a very heavy view that mixes business logic with presentation logic, and a controller that does almost nothing.
    The real difference though is that the controllers in a GUI app. both present the button and hand off the results of the click.
    Really? I thought the view (aka GUI) presents the button and the event-handler hands off the results to the controller.
    With PHP the whole controller is ripped to bits at the end of the presentation process. Then the session starts another page and we have to find out what controller we were using so that we can finish the request.
    The end of the presentation process is handled by the view. No controller anywhere in sight. (The last controller "died" when it handed off to the view.) The request then hits the next controller and the process starts over.
    This doesn't hold up. If you have just come from a form then that form data will have to be dealt with before anything else. As this data came from a view, then this view will have to be found. This means that the initial order will be control logic, view (to parse the data) and then model.
    Since the View is all about presentation, I can't see why it should have anything to do with parsing input data. The point of the separation is that it shouldn't matter where the input data came from. All processing of input is handled by the (Input) Controller.
    The result of the model interaction will be a result, either success or an error. Some more control logic can then decide the next view.

    Even without a form you could be using a clients previous history to decide the next view. The initial start up is still control, view, model.
    IMHO it is Controller (to look at the input and call the appropriate behaviour on the...), Model (do perform any domain logic), (briefly back to the) Controller (probably an Application Controller to decide on the next) View.
    To me the current state of a shopping basket is a property of a view as it would only apply to a web interface. In fact the Basket itself would probably not exist in the database except when gathering usability statistics. It would become a Purchase at the end of the transaction.
    When designing eCommerce applications, I always see the shopping basket as part of my application metaphor. As a result, the ShoppingCart object sits smack in the middle of my Domain Model, and quite naturally gets persisted to the database, tied to the user's session, and if he's logged in, the session is tied to his User object (also part of the DomainModel).
    If you call it a controller though, then MVC has to become MVCC.
    I see the "Navigator" as part (or helper) of the first "C", not as a separate second "C".
    The endless MVC discussions don't seem to go anywhere. Even Fowler devotes only a half page to it in the whole book.
    In my copy it's 3 pages (330-332)...
    MVC is either just an option of many, or it's a unifying concept that covers all of the above. If it's the former then there are better descriptions available and if the latter then it's pretty useless anyway.
    I see it as a meta-pattern, that shows us how the three parts (which are implemented using any number of the other patterns) can work together while minimizing the coupling between them and keeping the underlying design decisions reversible.
    Sorry about the length of this reply Jochen , It's just that I feel we are getting somewhere .
    Let's have longer replies then, and we might reach MVC-Nirvana some day .
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  2. #27
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Still a bit of a mess, but here goes...

    I think the problem originates from the type of question people asked themselves when they started implementing MVC in web applications: they asked "how can I solve this problem using MVC?" instead of "what is the best solution for this problem?" or even "what exactly is the problem I'm trying to solve?". Quite a number of people seem to have created a sort of mental link between web apps and MVC; you have to use MVC for your web app if you want to separate business logic from presentation. You're not allowed to stray from the MVC ideology, because MVC is the only 'right' solution. Well, when your entire application creaks and bulges, then you're probably using the wrong architecture (or abstractions).

    Quote Originally Posted by ZangBunny
    Quote Originally Posted by lastcraft
    The template may dictate (with custom tags) the domain code that gets executed and so may be more than just a view. Templating is mostly orthogonal.
    It could, but then it wouldn't belong in an MVC architecture. In a clean MVC only the controller can nudge domain code into execution. It then collects the domain objects that result from the logic and hands them off to the view for display. The view should strictly speaking do nothing more than use getters on the domain objects and put their data into the right template variables (if you use one).
    If lastcraft's solution solves the problem neatly, and MVC doesn't, then maybe we should abandon the MVC architecture, and define our own. I've seen so many people say things like "Controllers are actually Actions", "sessions belong both in the Model and in the Controller". Well, if Controllers are Actions, we should call them Actions. If sessions are needed in two layers, maybe our layering is just wrong... Everyone is using MVC because that is the pattern to use, and we're disregarding perfectly good suggestions, just because they don't fit into the MVC structure.

    I think lastcraft was right when he said the "web application" doesn't really exist. I don't agree with his 'illusion create by a sequence of scripts', though. I prefer to blame the user here; we create the impression (for ourselves) of a web application based on the structure of the content, and the links to related subservices.

    This has led me to what I now consider the main responsibility of stateless webservices : Resumption of Service. It means that we should embed references to related services in each Document we send to the client, so that the client can access these other services on our server.

    A web application has an Action defined for each valid Request from a client. Data is often retrieved from a DataSource, transformed into the correct format, and merged into a predefined Document template. A Response (which includes the Document) is then returned to the client. The web application has no real idea what the Document it's returning means, nor does it care. Its only job is to find the Action needed to perform the incoming Request, initiate the manipulation and transaction of whatever data is needed for the Document template, and join them together. The client software generally doesn't know the meaning of the Document either. It just knows how to parse/process/render certain types of Document (HTML/XML/RSS/txt). It doesn't know (or care) about the business logic on the server side either; all it knows is that the user clicked on a link, so it sent a Request to the specified server, and now it's got a new document to display. It may not even be the Document the user expected, but it's all there is to display right now...

    Some people may claim that it's possible to fit everything I just said into the MVC pattern. And they would be right. But let me say this: I could fit the act of putting on my socks into MVC as well. But just because we can, doesn't mean that we should (or that doing it is sensible). I think there are some important differences between what MVC stands for, and what it actually is that our applications do:
    • RAR: Request - Action - Response. It's the web server's job to send a Response for each Request; if we don't do this our service will appear to be broken. In our case, the web server lets PHP handle the Action.
    • we work in an environment where most concerns are solved by other pieces of software. User interface, network transactions and routing, document parsing, etcetera, all take place elsewhere. All we need to worry about is the Document that needs to be returned to the client, inside the Response.
    • the View is far more complex than a Document, since it has to be able to send and receive messages from other parts of the application. A Document is merely a piece of text, probably using some subset of XML (but we don't really care; it's the client's job to make sense of it).
    • a Controller has a far more direct relation with the user interface than an Action (which has no relation to a user interface whatsoever). A Controller handles an event triggered by user input, an Action performs a series of commands and requests to business components and combines their output with a Document template.
    • There is no such thing as WorkFlow. Clients are given options for future Requests, which should be related to the content of the current Document. This means that the entire structure of the application exists as links inside the Document templates, and by the grace of the client software, which is able to extract these links and interpret them as possible requests to our service.
    • there are no users, only clients. When we send a Document to someone (or something), what will happen to it? Do we even care? It might be someone's browser. It might be an aggregator, or a search engine that made the Request. Does it matter? No. All our application should care about is returning the correct Document.


    Am I making any sense at all here? I'm still busy refactoring these ideas...

    As for my own application's structure: I don't really use any layering or structure. I've created components for every concern that is a part of my application (Source_Request, Source_Database_MySQL, TextFilter, Source_Template, Action_ShowPage), and there is a single static class that returns and stores instanciated components, and can fetch new ones (sort of a SingletonFactoryRegistry or whatever). Each component theoretically has access to all other components, it's just that they are mostly unaware of eachother's existence, and they only care about the components they need to perform their own tasks.

    I basically have two types of Actions: those that compose the Document specified by a GET Request (or a login/error Document), and those that modify data based on a POST Request, and then return a redirect Document (or the original form Document, if data is missing). Content is generated by Block components, which take care of their own caching/logging/security/etc. Their output is a partial Document, which can be inserted into a main Document. My Template component currently uses a mixture of push and pull: data is pushed, Blocks are pulled.

    Still not entirely happy with my post, but I'm fed up with pressing 'Preview Reply'.

  3. #28
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Some people may claim that it's possible to fit everything I just said into the MVC pattern. And they would be right.
    MVC is not a tight frame that you have to bend and stretch to fit things into it that don't belong in it. It is a general scheme that separating domain logic (Model) from presentation logic (View) and connect one to the other in a flexible way (Controller).

    I think we all agree that the first separation is useful for building web applications, then the second follows logically from trying to minimize coupling and keeping the application flexible. This is what MVC is all about.


    Quote Originally Posted by Azmo
    A web application has an Action defined for each valid Request from a client.
    That's what MVC calls the Controller.
    Data is often retrieved from a DataSource,
    ... still the controller.
    transformed into the correct format, and merged into a predefined Document template. A Response (which includes the Document) is then returned to the client.
    ... the View.
    The web application has no real idea what the Document it's returning means, nor does it care.
    That's why the View is separated from the Model and the Controller
    Its only job is to find the Action needed to perform the incoming Request, initiate the manipulation and transaction of whatever data is needed for the Document template, and join them together.
    In MVC terms: The Controller initiates the required business logic, and hands the result to the View, which uses a template to merge the data into the document.
    Some people may claim that it's possible to fit everything I just said into the MVC pattern. And they would be right.
    Because what you just said is MVC put in different terms.
    I think there are some important differences between what MVC stands for, and what it actually is that our applications do:

    * RAR: Request - Action - Response. It's the web server's job to send a Response for each Request; if we don't do this our service will appear to be broken. In our case, the web server lets PHP handle the Action.
    Action === Controller (?)
    * the View is far more complex than a Document, since it has to be able to send and receive messages from other parts of the application. A Document is merely a piece of text, probably using some subset of XML (but we don't really care; it's the client's job to make sense of it).
    When a document is all we can send to the client, how else but through the document should we send/receive those messages? Of course the messages will have to be embedded in the document in some way. In MVC terms the part of the Application that handles that is called "View".
    * a Controller has a far more direct relation with the user interface than an Action (which has no relation to a user interface whatsoever). A Controller handles an event triggered by user input, an Action performs a series of commands and requests to business components and combines their output with a Document template.
    That's why it is sometimes (as in PoEAA) called an "Input Controller". It handles user input, decides which "Action" (business logic) needs to be performed, and then hands over to the View that created the output (using a Template).
    * There is no such thing as WorkFlow. Clients are given options for future Requests, which should be related to the content of the current Document. This means that the entire structure of the application exists as links inside the Document templates, and by the grace of the client software, which is able to extract these links and interpret them as possible requests to our service.
    Not necessarily. In complex application, the next "page" the user sees depends on more than the link that he clicked. When he clicks "next" in a multi-page wizard style workflow, the application decides what the next page (or form in that case) will be, based on user input and internal state. In this case, the Controller uses another pattern called "Application Controller" (or "Navigator") to decide which View to display next.
    * there are no users, only clients. When we send a Document to someone (or something), what will happen to it? Do we even care? It might be someone's browser. It might be an aggregator, or a search engine that made the Request. Does it matter? No. All our application should care about is returning the correct Document.
    No argument here.
    I basically have two types of Actions: those that compose the Document specified by a GET Request (or a login/error Document), and those that modify data based on a POST Request, and then return a redirect Document (or the original form Document, if data is missing). Content is generated by Block components, which take care of their own caching/logging/security/etc. Their output is a partial Document, which can be inserted into a main Document. My Template component currently uses a mixture of push and pull: data is pushed, Blocks are pulled.
    Seems like you are using MVC: Your Actions are the Controllers, GET Request lead directly to the View, while POST requests first trigger some business logic and then go to the view.
    [quote]
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  4. #29
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Great posts everyone. I'd like to second the opinion that there seems to be a tendency to ask questions like "how do I solve this using MVC", or likewise, "how do I solve this using [some Design Pattern]".

    I think that a lot of people haven't "found the need" to use MVC, but they just want to use it because it is indeed a buzzword (at least on these forums ). For me, the need to use a MVC-like pattern (there is no "MVC pattern" defined for web applications, because it is essentially a pattern for desktop GUI applications) arose from having to support multiple presentation layers to one of my applications. My previous apps contained mixed model, view and controller code that made it hard to support another web interface (like WAP) to it.

    Here's something that comes to mind: The key to understanding the solution is to understand the problem. I think that saying is very applicable to the last couple of posts of this discussion. Because people don't understand their application's [design] problem, or in fact don't have it, they won't understand why the solution should be as it is either.

    Also, I think that MVC is part of a "bigger whole", something that I've seen called "separation of concerns" or "SoC". That is after all what MVC is about! putting code with different responsibilities that should not be mixed into different classes (layers if you will), to create more flexible and reusable code designs. But MVC is not where SoC stops, you can apply it to your entire application. I even believe that SoC is something like a 'natural cause of evolution' of object oriented programming.

    Well, hopefully some useful stuff to discuss about..

  5. #30
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Great posts everyone. I'd like to second the opinion that there seems to be a tendency to ask questions like "how do I solve this using MVC", or likewise, "how do I solve this using [some Design Pattern]".

    I think that a lot of people haven't "found the need" to use MVC, but they just want to use it because it is indeed a buzzword (at least on these forums ). For me, the need to use a MVC-like pattern (there is no "MVC pattern" defined for web applications, because it is essentially a pattern for desktop GUI applications) arose from having to support multiple presentation layers to one of my applications. My previous apps contained mixed model, view and controller code that made it hard to support another web interface (like WAP) to it.

    Here's something that comes to mind: The key to understanding the solution is to understand the problem. I think that saying is very applicable to the last couple of posts of this discussion. Because people don't understand their application's [design] problem, or in fact don't have it, they won't understand why the solution should be as it is either.

    Also, I think that MVC is part of a "bigger whole", something that I've seen called "separation of concerns" or "SoC". That is after all what MVC is about! putting code with different responsibilities that should not be mixed into different classes (layers if you will), to create more flexible and reusable code designs. But MVC is not where SoC stops, you can apply it to your entire application. I even believe that SoC is something like a 'natural cause of evolution' of object oriented programming.

    Well, hopefully some useful stuff to discuss about..
    Well, I got suprised when I saw that examples of design patters were in Java Servelets, I saw them on java.sun.com or on www.java.net, so even they are trying to apply those patterns to web applications.

    Yes, I think that we probably shouldn't stop with MVC, separation of layers is a good thing, but we perhaps need to invent other pattern that will be more suitable for web applications.

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

    Why cars are airplanes, and how to fit a round peg in a square hole.

    Because what you just said is MVC put in different terms.
    Here's something I just thought of which may clear up why different terms matter: A car is the same thing as an airplane. The only difference is that a car never leaves its runway. And it generally has four wheels instead of three. And it doesn't have wings because it doesn't need them. Or a tail rotor. And there's only one driving seat, instead of two. And there are airbags instead of oxygen caps. And it won't kill you if you open a window while you're flying.

    As you can see, I'm quickly running into problems when I try to describe a car as being an airplane. That's because a car, although similar to an airplane in some respects, is not an airplane. So the idea of an airplane, when applied to a car, is probably an incorrect abstraction (or metaphor?). While it's perfectly possible to get by in real life referring to cars as 'planes', it will cause a lot of confusion.

    Zangbunny: In your latest response to lastcraft, you appear to be talking about desktop applications (MVC-UI). But in your reply to my post, you refer to the generic nature of MVC (as in Model 2). As long as the majority of people make no distinction between MVC-UI and Model 2, and refer to both as 'MVC', we will all continue to be confused and frustrated by what we think is one pattern.

    That's why I'm staying as far away from the whole idea of MVC as I can; my framework may look very similar to either of the MVC interpretations in some ways, but I'm claiming it's not, simply because I want to avoid getting bogged down in a discussion where nobody even knows which side they're on. Separation of concerns: yes. Separation of business logic and presentation logic: yes. But I'm not even going to consider calling this MVC as long as even a fraction of the current confusion surrounding this pattern remains.

    Btw: Model 2 might very well be appropriate in the webservice domain. But it may be better to ignore this fact, and present an equal or similar solution with a different name, so we can help end the confusion and the myth surrounding MVC.

  7. #32
    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)
    It seems that this discussion seems to move me towards accepting the proposition that MVC is a paradigm, not a pattern.

    from http://www.c2.com/cgi/wiki?ModelViewController
    Like the original MVC article's title -- "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80" (Glenn Krasner and Stephen Pope, JOOP, August/September 1988) -- says, it's a paradigm. It's a conceptual framework for designing and implementing graphical user interfaces. A class library, such as Smalltalk-80's, would typically implement MVC based on abstract classes and default method definitions for models, views, and controllers -- a Framework! -- MitchellModel
    Based on that, I think it is easy to say that Models are the business logic, Views are presentation and Controller directs application flow (or is everything not a model/view) however, without a specific implementation in PHP this does not really lead to a shared understanding between developers.

    Also, I think Java is a great source for understanding OOP and patterns, however I think the most fundamental difference between Java and PHP for web pages is the lack of an application container (as others have mentioned before, PHP is stateless - meaning that the entire structure of the framework must be reloaded and reparsed and reconfigured for each request, whereas under an application server environment, parsing and configuration is done once and can continue to be reused for many requests).

    I think this is the core item to address when trying to port/emulate/improve/design and MVC framework in PHP.

    @ZangBunny - Of these PHP MVC frameworks http://wact.sourceforge.net/index.ph...ksWrittenInPhp , which have you looked at and of those, are there any that you feel adequatly reflect a PoEA view of MVC?

    Regards,

    Jason

  8. #33
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    @ZangBunny - Of these PHP MVC frameworks http://wact.sourceforge.net/index.p...rksWrittenInPhp , which have you looked at and of those, are there any that you feel adequatly reflect a PoEA view of MVC?
    I must confess, of all these I only ever looked at Phrame and discarded it quite quickly. Trying to port a Java Framework to PHP doesn't seem like a good idea to me, because PHP is not Java (stateless vs. container).

    I find myself rarely using frameworks directly, apart from the one we created for our own use at work. That one wasn't created as a framework from the start (which is a bad approach anyway, IMHO) but rather are the result of reusing and refining a basic set of classes through several medium to large scale projects.

    I also don't think one can gain a deep understanding of a design pattern from looking at a framework or application that implements it, but only from applying the pattern to a fitting problem oneself.

    Quote Originally Posted by Azmo
    In your latest response to lastcraft, you appear to be talking about desktop applications (MVC-UI). But in your reply to my post, you refer to the generic nature of MVC
    I made the reference to GUI applications because Marcus tried to point out a difference between GUI applications and web application that I don't think exists. The main difference comes from the fact that (as Fowler says) even most versions of Smalltalk didn't implement MVC correctly, whereas web applications force you to do it right.

    In a well layered application, it shouldn't matter much wether it is run through a GUI or a web interface. When writing a GUI, it shouldn't matter wether the domain logic runs locally or is accessed remotely, using web services provided by the company's mainframe.

    The individual processing steps may be more fine grained, but I don't see a fundamental difference between GUI and web interface, as long as we're talking about "enterprise applications", i.e. multi-user applications running against a central data-store, not "office software" or games.

    Enterprise applications work the same wether they use a GUI or a web interface: You enter the information for your request in a form, press "submit" or "ok", and get the result back from the application server or database. This is the reason why the majority of ERP vendors use web interfaces today: They do the same as the GUI front-ends and are easier to implement and deploy.
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  9. #34
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi Jochen.

    I'll reply just to mine, otherwise you'll be typing until Doomsday .

    Quote Originally Posted by ZangBunny
    But this way, you have a very heavy view that mixes business logic with presentation logic, and a controller that does almost nothing.
    Yep. I also have a very clean separation which I can apply right from the beginning of a project and one that the business people can understand.

    The mixing of "business logic" does not happen. All of the logic in the view here (the basket mechanics) is with usability and web marketing. So are the colours in the template. The view delegates to the model to for persistent actions and data (finding prices, dispatching). If MVC makes everything into "business logic" then something is very wrong with it indeed.

    As the site gets larger this can grow into a full blown presentation tier. At that point we have left MVC behind except possibly for a very thin veneer atop this presentation tier. Looking at it this way MVC is so imbalanced (99% is the M) it is completely useless as an architectural pattern. It becomes an implementation footnote.

    Quote Originally Posted by ZangBunny
    Really? I thought the view (aka GUI) presents the button and the event-handler hands off the results to the controller.
    OK, that was a flu addled brain trying to be brief . The controller delegates to the view in both cases, but the order of the events is the same.

    Quote Originally Posted by ZangBunny
    The end of the presentation process is handled by the view. No controller anywhere in sight. (The last controller "died" when it handed off to the view.) The request then hits the next controller and the process starts over.
    No that's not what I was trying to get at. I was trying to map the GUI versions of MVC onto web page version and explain how it all gets messed up. Your reply further emphasises that the GUI and web versions of the C are not even closely related. The controller death is very Swing btw, is that the example you are drawing from?

    Quote Originally Posted by ZangBunny
    Since the View is all about presentation, I can't see why it should have anything to do with parsing input data. The point of the separation is that it shouldn't matter where the input data came from. All processing of input is handled by the (Input) Controller.
    Flu again ; I'll be more precise. The controller can extract the parameters and present the resulting action to the view. The FrontController pattern is nearest to MVC here in that the C actually has something to do. Interpreting the resulting parameters is the job of the view. For example this URL fragment...
    Code:
    ...stuff.php?a=edit&name=fred
    The "a" parameter is clearly part of the FrontController regime. The "name" parameter clearly belonged to whatever view we just left. We would like to reunite it with the same class again (otherwise the "name" key is magic). That view is the only one that knows the correct interpretation of "name". The view can then call setName('fred') on the appropriate model object.

    The alternative you suggest is more messy. If the controller is to call setName('fred') then it need to know in it's entirety how to interpret the incoming parameters. The control code is so closely tied to the view that "separation of concerns" has disolved.

    Quote Originally Posted by ZangBunny
    When designing eCommerce applications, I always see the shopping basket as part of my application metaphor. As a result, the ShoppingCart object sits smack in the middle of my Domain Model, and quite naturally gets persisted to the database, tied to the user's session, and if he's logged in, the session is tied to his User object (also part of the DomainModel).
    Ok, we definitely diverge at this point. I won't go into this further as it gets away from the topic of the original post. I'll have to start a "presentation tier" thread at some point.

    Quote Originally Posted by ZangBunny
    I see the "Navigator" as part (or helper) of the first "C", not as a separate second "C".
    We obviously agree here, as does our original poster. I think MVCC explains more than MVC though. I think MVC is actively misleading.

    That second C actually has all of the code that will change when the site is restructured. In other words all of the maintanance headaches are in that little extra C.

    Quote Originally Posted by ZangBunny
    In my copy it's 3 pages (330-332)...
    Sorry, I was thinking of just the last half page (p332) where he splits VC. Anyway, compare this with the amount of content on persistence to see the relative importance attached. It was this I was tring to get at.

    Quote Originally Posted by ZangBunny
    I see it as a meta-pattern, that shows us how the three parts (which are implemented using any number of the other patterns) can work together while minimizing the coupling between them and keeping the underlying design decisions reversible.
    Is it a meta-pattern that is only found by post-rationalisation? A pattern should be useful when you first walk up to a problem. What are your thought processes when weighing the pros and cons of MVC versus other alternatives? Can you give an example of where you would reject an option in favour of MVC? I am sure that you can, but personally I do my comparison with the more precise versions we have already mentioned.

    There are other problems that seem to weaken it further...

    The template contains control information. It does this every time you add an anchor tag. You need to generate all such links to be strict MVC. This is overkill even when using front controller style links unless you somehow build it into your template engine. Except that if you build it into your template engine you are breaking MVC again. Seems you cannot win.

    If you use smart widgets (e.g. JavaScript generators) with complex selections then the only way to interpret data is via. those widgets. This means all interactions must go through the views.

    It doesn't seem to explain how things are going to scale. You have to create a controller pretty much for each view. This per. view controller is different from the one that finds the right view in the first place. So that's an extra controller. Am I really the only one confused by now? In the OO world you are likely to have multiple domain objects, each with viewlets say, so that you can rearrange the content flexibly. Does each subview have it's own controller? If you do then in MVC you will have to build your C tree as well as your V tree . I think MVC is anti-OO here. It requires a god controller indeed if it is going to assemble all of the views and read all of the input data, rather than let them build their own children. This is an unlikely case (I have never needed it), but one that is easily dealt with by custom tags.

    Quote Originally Posted by ZangBunny
    Let's have longer replies then, and we might reach MVC-Nirvana some day .
    This group is the place to be in PHP right now. There is obvious progress over time with the different discussions and new stuff gets started here.

    And everyone is both enthusiastic and polite .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  10. #35
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The view can then call setName('fred') on the appropriate model object.
    Now that is a _fundamental_ misconception which I must fight with all my heart Views should never manipulate (or 'send data to') Model objects, that is the Controller's job. The sole purpose of views is to get data from a model object and format it for presentation, which usually means wrapping a template around it. If you think that View objects can manipulate the Model objects, you are really wrong. Go and study any article on MVC by someone with authority, Martin Fowler for example, and you'll find that this is not the way to go.

    The alternative you suggest is more messy. If the controller is to call setName('fred') then it need to know in it's entirety how to interpret the incoming parameters. The control code is so closely tied to the view that "separation of concerns" has disolved.
    Manipulating the model, i.e. setName('fred') is exactly what the Controller was invented for in the first place! The separation of concerns between the View and the Controller is that the view merely 'presents' (extracts data from the model and formats it) and the controller 'manipulates' the model and chooses a view depending on the result of that manipulation.

    The controller's job *is* about knowing how to interpret incoming parameters: what to do with those parameters to manipulate the model! A view does not care where its parameters come from: an incoming form request, something stored in a database, it's all the same to the view. It also should not care about the validity of the incoming parameters, because that is the job of the controller to look after.

    The template contains control information. It does this every time you add an anchor tag. You need to generate all such links to be strict MVC. This is overkill even when using front controller style links unless you somehow build it into your template engine. Except that if you build it into your template engine you are breaking MVC again. Seems you cannot win.
    That is not control information, it is navigation information, something that is inherent to every type of View. Think of similar 'links' in desktop GUI applications and command line applications. These links are part of the view, the view knows where it can send a user to, it has to present application links somehow. The fact that the adresses of these links are somewhat complex (bla.php?a=edit&whatever=someID) does not mean that a View is not allowed to generate them, that logic is in my opinion not logic that belongs in a Controller-like layer.

    If you use smart widgets (e.g. JavaScript generators) with complex selections then the only way to interpret data is via. those widgets. This means all interactions must go through the views.
    JavaScript code that contains presentation and application control logic can be seen as part of the controller layer. The fact that this code is embedded in the HTML template ('the view') is just a means to an end. 'The view', as in 'the HTML page that is seen in the browser' is not the same concept as 'the view layer' of an application incorporating the MVC pattern.

    How exactly JavaScript form controlling / validation fits in MVC is a hard thing to grasp, but that is because of the unique stateless nature of the web and the non-stateless nature of a dynamic html page in a browser. Compare it with a desktop application where the kind of logic that JavaScript is used for on the web, form controlling, is coded in a controller, one like in the original (desktop) MVC pattern. Form controlling logic is coded in the controller, and it can be done to code it in such a way, that you can convert that logic into equivalent javascript which you can then pass to your view.

    When your user interface is dynamic, it's a different story. To me it seems logical that the code you then need to control the user interface can be coded in the view layer (Remember, like with the templates debate, code inside templates / views is not by definition a violation of separation of kinds of logic).

    It doesn't seem to explain how things are going to scale. You have to create a controller pretty much for each view. This per. view controller is different from the one that finds the right view in the first place. So that's an extra controller. Am I really the only one confused by now? In the OO world you are likely to have multiple domain objects, each with viewlets say, so that you can rearrange the content flexibly. Does each subview have it's own controller? If you do then in MVC you will have to build your C tree as well as your V tree . I think MVC is anti-OO here. It requires a god controller indeed if it is going to assemble all of the views and read all of the input data, rather than let them build their own children. This is an unlikely case (I have never needed it), but one that is easily dealt with by custom tags.
    First of all, MVC is just 'a', not 'the', pattern to use. The fact that there is one controller per view is something that is inherent to MVC. The reason for this is that for each controller-view combination, there are tasks involved that are better separated into two objects/classes, (separation of concerns, remember? ) It is a way of structuring the code of a presentation layer of an application that I believe is most flexible, and isn't that what OOP is about in its core: finding a flexible class/object structure that supports code reuse and scalability? I think it is. MVC, if you understand the pattern and how to apply it to the web, does explain how things are going to scale. When your application model has been coded, you can theoretically add as many presentation layers (XML-RPC, SOAP, HTML, WAP, RSS, PDF, you name it) on top of that one same model, without having to adapt your model. That is where the scalability and flexibility of the pattern is found in.

    I understand what you mean by subviews, it's a problem I have tried to dealt with theoretically as well. First of all, what is your definition of 'subviews'? If subviews mean multiple forms on one page, then maybe I have a solution to that here. Forms are where the job of the controller becomes most obvious. Multiple forms is not a problem, but you have to somehow change your way of thinking about controllers. A controller for a view does not have to be 'one object', it can be one object that calls in the help of many other objects, still in that controller layer. In my application, each form in the user interface has its own, what I call, FormModel. Not to be confused with the (Domain) Model like the M in MVC, because that's a different thing. This FormModel is an object that encapsulates the form validation logic for a form. When you have multiple forms in one view, you can pass the view object the specific FormModel objects for the forms on that view. Allright, but I'm sure the question you will ask now is, how are the submissions of these forms handled, by that same controller or by different controllers? I think the most flexible solution is to have those handled by other controllers, by having each of the forms submit to a different URL. The other controller can then check the FormModel for the specific form that has been submitted and see if the data is valid, etc. If the data is not valid, it can create a view and pass it the FormModels for each of the forms on the view.

    The MVC pattern does not mean that some god controller has to assemble a whole bunch of controllers and views: each view only has one controller associated with it, but like I explained in the above paragraph, the control logic for 'subviews' (forms) can be delegated to other controllers. Maybe it also helps not to think of a controller being tied to a single view, but to a single action. This is actually true, because a controller can choose different views as the result of manipulating a model, so it is by definition not tied to one single view. Think of a controller as being responsible for an 'action', for example the submission of a form.

  11. #36
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    OK, you are fairly strident in your MVC.

    Quote Originally Posted by Captain Proton
    Now that is a _fundamental_ misconception which I must fight with all my heart Views should never manipulate (or 'send data to') Model objects, that is the Controller's job.
    I wasn't misconceiving here, I was disagreeing by presenting an alternative architecture. Anyway, why is it the controller's job? Which controller for that matter? Where is it written from above that we must follow MVC? There are alternative approaches and discussing them is not heracy.

    The strong view approach actually works very well in a lot of cases, especially for complex content with many sub controls. A bunch of grid controls on a page is a good example. The sky certainly does not fall in.

    Quote Originally Posted by Captain Proton
    The sole purpose of views is to get data from a model object and format it for presentation, which usually means wrapping a template around it. If you think that View objects can manipulate the Model objects, you are really wrong.
    If you think that a view is just a template and the code to populate it, then you must logically put all of the processing code into the controller. For the controller to pick apart the form data, though, it has to know a lot about the template structure because of the way all the data has to come in a batch in PHP. Change any widget in the template and you have to change the controller. What is this telling you?

    Quote Originally Posted by Captain Proton
    Go and study any article on MVC by someone with authority, Martin Fowler for example, and you'll find that this is not the way to go.
    There was me saying how polite everyone was .

    Quote Originally Posted by Captain Proton
    Manipulating the model, i.e. setName('fred') is exactly what the Controller was invented for in the first place! ...
    The controller was "invented" to interpret mouse clicks and keyboard. Anyway, you are describing MVC again. The more interesting stuff to me is finding out how applicable it is to solving web development problems.

    Quote Originally Posted by Captain Proton
    That is not control information, it is navigation information, something that is inherent to every type of View. Think of similar 'links' in desktop GUI applications and command line applications. These links are part of the view, the view knows where it can send a user to, it has to present application links somehow. The fact that the adresses of these links are somewhat complex (bla.php?a=edit&whatever=someID) does not mean that a View is not allowed to generate them, that logic is in my opinion not logic that belongs in a Controller-like layer.
    Which means that the controller is a left over hotch potch. The really important stuff, navigating the whole site, is now the property of the view. Navigating the site is also the job of the ApplicationController (damn I said it). This is the contradiction I was illustrating.

    Quote Originally Posted by Captain Proton
    JavaScript code that contains presentation and application control logic can be seen as part of the controller layer...
    Your explanation just muddles things further for me. I find your categorisations and justifications rather arbitrary to be honest. How does MVC cause you to use or not use a JavaScript control? Such a decision is right within the domain of this pattern and yet it has nothing to say.

    That these things are far from obvious demonstrates that MVC lacks power as a design idea. I don't think about what parts of the JavaScript control are control, view or it's own model or how it fits with the view or whatever above. I just have a Widget class or a custom tag that behaves just like any other control. Usually that means it looks after itself accross page requests and I can validate it. Whether it is a "means to an end to embed it in a view" or not I don't really care as it actually only has one place to go. I just get on with factoring the application using more effective metaphors.

    Quote Originally Posted by Captain Proton
    MVC, if you understand the pattern and how to apply it to the web, does explain how things are going to scale. When your application model has been coded, you can theoretically add as many presentation layers (XML-RPC, SOAP, HTML, WAP, RSS, PDF, you name it) on top of that one same model, without having to adapt your model. That is where the scalability and flexibility of the pattern is found in.
    There are two views of this depending on at what level you choose to cut your...er...views. If you are saying that you can change from HTML to SOAP then you are out of the realm of InputControllers and the like. The HTML interface may use a shopping basket, whereas the the SOAP interface would likely involve document exchange. The structure of these would be radically different, hardly a pattern. So I described this as a presentation tier as you do.

    Now, the same question to you as Jochen, is the shopping basket in the domain or the view or the controller? If it is the domain then the higher level separation was not achieved with MVC.

    Quote Originally Posted by Captain Proton
    First of all, what is your definition of 'subviews'?
    I was thinking of a side by side display in my head, but subforms will do as long as they are common over the application. With a side by side display I am assuming that you will want to reuse the code from the lone display.

    Quote Originally Posted by Captain Proton
    A controller for a view does not have to be 'one object', it can be one object that calls in the help of many other objects, still in that controller layer. In my application, each form in the user interface has its own, what I call, FormModel.
    I have unfortunately seen this used before in a Swing app. The main model was called the SuperModel in this case. So now it is MMVC?

    Quote Originally Posted by Captain Proton
    This FormModel is an object that encapsulates the form validation logic for a form...
    I once attempted the same thing, but the class structure just got horrendous along the same lines. The code is speaking to you at this point and you are fighting it.

    Here is what happens when you place all those problems into a combined controller and view and use a bit of XSLT...
    Code:
    Find my hire vehicle:<br />
    <form>
    Number of doors:
    <input type="text" name="n" value="4"
            validate="TwoToFive" key="door_count"/>
    <input type="submit"  validate="inMidlifeCrisis" target="show_car"/>
    </form>
    Without the need for FormControllers I have Validators pure and simple. They can be passed into a generic form or attached to a widget. As I am assigning these within the template itself, I don't need code to build each form. In fact I can cut and paste this code into any other part of the app. and regenerate the PHP. By making the view dictate the structure of the app. I can hide all of the repetitive control logic and expose the real decision makers. Here the InMidlifeCrisis object will be passed into the form. The show_car script will be told "Porsche 911 turbo" in my case, although probably not if it has access to my driving history.

    I am clearly making this up off the top of my head, but I can visualise how the code will pan out and I am sure you can too. You can probably post rationalise this into MVC with the inevitable loose ends, but I doubt it. I don't have a one to one mapping from view to controller here.

    I am using patterns here though. The Visitor, ApplicationController, Composite, TemplateView, Command and Bridge will all feature.

    Quote Originally Posted by Captain Proton
    Think of a controller as being responsible for an 'action', for example the submission of a form.
    Then call it an Action. What do you then call the FrontController which handles multiple actions. What if the action has to be filtered through an ApplicationController? These are big decisions. Calling them all MVC doesn't help you select between them.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #37
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Palo Alto
    Posts
    179
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    The controller can extract the parameters and present the resulting action to the view. The FrontController pattern is nearest to MVC here in that the C actually has something to do. Interpreting the resulting parameters is the job of the view.
    After my earlier rant, I think I may have to eat my words. This quote by lastcraft made me realize that I don't think of MVC as a pattern unto itself, I see it as a metapattern (to steal ZangBunny's term). Ergo, the model can be a DomainModel or TransactionScript, etc.; the view can be Template or Transform, etc.; the controller can be FrontController or PageController, etc. I reread Fowler's presentation patterns and a little of Core J2EE Patterns, and I think my interpretation of MVC may have been wrong. (Of course, I may be the last one to realize this... it wouldn't be the first time.) If I was wrong, then I must agree with lastcraft and call MVC a rather useless architectural pattern. However, if part of the point of this discussion is to come to some agreement on an appropriate pattern (or vocabulary, as the case may be), then I'd like to point out that my interpretation of MVC as a metapattern -- however wrong it might be -- proved enormously helpful. While I may or may not have a clear understanding of MVC, I do feel I've got a pretty solid grip on separation of responsibility within the presentation tier, and I got it by applying MVC as a metapattern. Right now I'm using DomainModel, a FrontController combined with a PageController-per-view, and TemplateView. I'd like to refactor a bit to reduce some conceptual duplication, but overall I'm pretty happy with it -- and I got it up and running in a matter of days (using TDD and SimpleTest, of course. ).

    Quote Originally Posted by lastcraft
    Ok, we definitely diverge at this point. I won't go into this further as it gets away from the topic of the original post. I'll have to start a "presentation tier" thread at some point.
    Please do, I think the shopping cart metaphor is a worthy discussion on its own.

    Quote Originally Posted by lastcraft
    We obviously agree here, as does our original poster. I think MVCC explains more than MVC though. I think MVC is actively misleading.
    Isn't the single C misleading only insofar as the M and V are misleading? Or am I (yet again) missing something?

    Quote Originally Posted by lastcraft
    A pattern should be useful when you first walk up to a problem.
    Given my recent epiphane, I'm almost certainly taking this out of context, but I would think this statement is only true if you have prior understanding of the pattern.

    Quote Originally Posted by lastcraft
    This group is the place to be in PHP right now. There is obvious progress over time with the different discussions and new stuff gets started here.
    Couldn't agree more.
    I think there is a world market for maybe five computers.
    - Thomas Watson, chairman of IBM, 1943.

  13. #38
    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)
    Rereading PoEA, reading this thread, and rethinking the applications I have developed using my current "MVC" architecture, I think that my implementation may actually be AC(MVC) Application Controller acting on Model-View-Command.

    Phrame as a port of Struts is basically a combination of a Front Controller and Application Controller. I view the job of Phrame to select the Action to take for any given request. In my case Actions are Commands (is a loose GoF sense in that Phrame will always select a given Action, and pass uniform arguments to the Perform() method).

    Whenever I do something like form processing, I have an action to process that form. That Action is then aware of
    a) the incoming HTTP request (i.e. $_POST)
    b) the structure of the View generated HTML page (so it knows what indexes of $_POST to extract)
    and c) what Models to instanciate, and what properties to use to achieve the desired result of the action.

    So, if I want to say add a field to be processed, I will need to:
    a) modify the Model to accept for update the new field
    b) modify the View to add a new field to the form
    c) modify the Controller to know to extract the request var and pass it to the Model::Update()

    What have I then gained? Not necessarily a separation of concern (as we just witnessed, it touched all three components) but what I have gained is a definite structure to my application. I know that all form processing will take place in actions. I know that all methods of my models that perform updates will (by gentleman's agreement ) only be called from Actions, not from Views, etc. So the main benefit appears to me structural, and maintenance (from a point of multiple developers becoming familiar with the structure and thus being able to maintain it effectively.) This same argument could probably be made for a number of other reasonable site architectures as well...

    As a side note, in a recent project I had a form with too many inputs, too much validation and too many changes in requirements coming in from the users, so I had to find a way out of the three step changes. What I did was to configure in the Model layer an array of metadata regarding the form structure, what type of input it was (text, numeric, select from a list, etc.), what validation was required, and some other application specific data. This array could then be passed to a view that would loop over the array and generate the form. The action that processed the update would request the form metadata from the Model, and then iterate of that to validate from the $_REQUEST and then trigger further appropriate Model methods.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #39
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    Sydney
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Still digesting most of the thread, but it is interesting to see how most people interpret MVC for PHP. Im pretty sure ive interpreted it in a way that is different from everyone else, but i find that how i work it suits me best and thats about all there is to it.

    I am always changing the layout of my MVC (type structure) to allow things to work best.

    Im thinking of trying a way where the model cant talk to anything, the view can only talk to the model and the controller just talks to the view. But i dont think it'll work out too well, will have to test it all firstly.

  15. #40
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @lastcraft: Would you care to put your alternative(s) to MVC in a pattern-like format so that we can compare the two on more even ground? So far, you addressed some isolated parts where you see alternatives, but I still fail to see the "big picture" how everything fits together.
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  16. #41
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Marcus, I'm sorry, I was not meaning to be impolite to you or anyone else. I just think that people like Martin Fowler have earned the reputation to be authority figures. It's definitely not that I blindly follow what he writes, but I have found the hard way that it makes sense. Believe it or not but I've been working on and off for one and a half years now on trying to create a flexible framework following (some kind of) MVC pattern, I've redesigned everything like 5 times, switched back to an another design, etc, and the solution I have now is flexible enough for my needs and I feel that it is 'elegant', enforces separation of concerns and is powerful.

    Then call it an Action. What do you then call the FrontController which handles multiple actions. What if the action has to be filtered through an ApplicationController? These are big decisions. Calling them all MVC doesn't help you select between them.
    What's in a name anyway. Just give the thing a name, and whether that's Controller, InputController, PageController or Action doesn't really matter to me, it's all the same.

    Could you give an example of when an Action has to be filtered through an ApplicationController please?

    I wasn't misconceiving here, I was disagreeing by presenting an alternative architecture. Anyway, why is it the controller's job? Which controller for that matter? Where is it written from above that we must follow MVC? There are alternative approaches and discussing them is not heracy.
    I would also really like to see a brief, structured overview of the alternative pattern you are suggesting. I will also prepare one for the MVC pattern I am suggesting, so maybe we can compare the advantages and disadvantages, which is what this discussion is all about, isn't it?

  17. #42
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by brainpipe
    Quote Originally Posted by lastcraft
    A pattern should be useful when you first walk up to a problem.
    Given my recent epiphane, I'm almost certainly taking this out of context, but I would think this statement is only true if you have prior understanding of the pattern.
    I'd say that a pattern can safely be applied only when you understand both the pattern and the problem.

    And IMO that's just the problem: a number of people decided they should use MVC (a pattern which many don't truly understand due to its ambiguity) for web applications, not realizing the significant differences between desktop applications and web services. What's even worse, is that the entire community is now trying to explain the problem domain using the terminology of an inappropriate pattern...

    As long as you define and describe the concepts and contexts of web services in terms of MVC, then your solutions will always end up being some derivate of MVC. And when MVC can't solve a problem, because it is not the best abstraction, it will appear as if the problem itself cannot be solved.

    It gets even worse: many expert coders have become so used to thinking of the problem domain in terms of MVC, that they automatically translate any other abstraction. Yes, you can claim an Action is a Controller, but in the problem domain we're dealing with, 'Action' is a far more descriptive name than 'Controller'. Yes, we can pretend there's a presentation layer, and we can call it the View. But it's an abstraction that creates a vast number of problems that seem extremely complex when viewed from an MVC perspective. By not talking about the problem we're trying to solve, but talking about the solution we want to use (whatever the problem may turn out to be) we also make the problems appear to be far more complex than they are in reality.

    If you still think it's 'right' to use MVC terminology for web services, please take another look at this entire thread. But instead of really reading it, look at the all fuzzy mini-discussions about the exact implementation and meaning of the various MVC components. And this is just one thread of many on one forum (of many forums). To me, this looks exactly like the discussions that would occur when an incorrect pattern or abstraction has been used to describe a problem. Things just don't fit, and instead of further solving the real problem, people get stuck trying to fit the problem into their incorrect solution.

    The really sad thing is this: there are no risks or drawbacks to defining the problem domain outside of MVC's scope. You can always come crawling back if whatever other abstraction turns out to be even less suitable than the MVC pattern. You'll even gain additional understanding about why the MVC pattern is better suited than the alternative. But if it turns out that MVC is inappropriate after all, then you'll be able to discuss and understand the real problems far more easily. Only then, once you truly understand what the problem is, can you make an educated evaluation of MVC's applicability in your problem domain. You may still choose to use MVC for your webservice software, but then it'll be because you know it is the best solution, not because you think it should be.

    All you need to do is to stop thinking in terms of Views, Controllers, and Models, and to stop using them when referring to aspects of your problem domain.

  18. #43
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One of the uses of a pattern is to provide names for the concepts it addresses, so that developers can use those names and everybody knows what they are talking about, because they know the pattern and know what e.g. a "Controller" is when talking about MVC.

    It would be nice if everyone who says he has a better pattern where to write it down in a pattern-like format and post it for discussion. That way we could talk about those patterns on the same level that we talk about MVC here.

    By claiming that MVC is not the best solution but keeping your better solution to yourself, you take from us the opportunity to appreciate your better solution or maybe find its shortcomings.

    So far, MVC is the only pattern I've seen formalized that addresses this particular problem, but I'm eager to see others.

    So, please share your patterns!
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  19. #44
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Palo Alto
    Posts
    179
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    What's in a name anyway. Just give the thing a name, and whether that's Controller, InputController, PageController or Action doesn't really matter to me, it's all the same.
    Language is everything. Appropriate terminology is a prerequisite for effective communication. It's no different than a programming language. Do we call this method "isAuthenticated" or "isAuthorized"? Does it really matter? I think it matters quite a lot. They mean very different things, and using the wrong term could (and most likely would) lead to a lot of confusion, particularly to anyone not privy to the original discussion and decision.

    Quote Originally Posted by Azmo
    I'd say that a pattern can safely be applied only when you understand both the pattern and the problem.
    And I'd whole-heartedly agree.

    Quote Originally Posted by Azmo
    What's even worse, is that the entire community is now trying to explain the problem domain using the terminology of an inappropriate pattern...
    I think the usefulness of MVC is part of the point of this discussion. Some people think it is, some think it isn't, and now we're to the point of looking for some concrete examples so we can all speak in the same language (i.e. code) and thereby communicate a little more effectively in the quest for an appropriate solution.

    Quote Originally Posted by Azmo
    ... look at the all fuzzy mini-discussions about the exact implementation and meaning of the various MVC components. ... To me, this looks exactly like the discussions that would occur when an incorrect pattern or abstraction has been used to describe a problem.
    Or the discussions that would occur when people simply don't understand the pattern (and/or the problem). Which, again, is the point of this discussion.

    Quote Originally Posted by Azmo
    ... there are no risks or drawbacks to defining the problem domain outside of MVC's scope.
    Agreed. In fact, and I'd suggest that not defining the problem from vastly different perspectives is a rather large obstacle on the path to a good solution. I've discovered this in programming -- if you stick to one language, you learn to define the problem in terms of that language only. Look around at other languages, and you start to see different problem definitions, which often leads to innovative solutions in the original language.
    I think there is a world market for maybe five computers.
    - Thomas Watson, chairman of IBM, 1943.

  20. #45
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by ZangBunny
    @lastcraft: Would you care to put your alternative(s) to MVC in a pattern-like format so that we can compare the two on more even ground? So far, you addressed some isolated parts where you see alternatives, but I still fail to see the "big picture" how everything fits together.
    Well, it's a bit vague to me, hence why I am sniping from the sides a little. Anyway, I'll ramble on with my own ideas so that everyone can have a go at me instead .

    I don't have a grand alternative scheme. In fact if it is possible to classify almost any set-up as MVC then alternatives don't exist. The main point is that there are less confusing ways of describing how to cut the code up. IMO ones that describe architectures more fully and much more clearly. I'll try to subdivide with some examples, but I am sure I am going to miss a shed load of alternatives.

    Within MVC having two controllers, a front/page controller and a navigator seems common for larger sites. This is one better described as MVCN to me (MVCP is not so clear I think) or simply as ApplicationController/Navigator. I cannot imagine anyone not separating the M and the V, so I think these can be taken as read.

    Without the N things start to get slightly ragged. The PageController concept needs some work I think, as this is what you get from naive coding anyway. Even the Fowler examples get rather cloudy on this pattern. Whatever architecture is used, no N means that the actions or steps in the navigation are distributed throughout the application. This isn't necessarily a bad thing, as a big monolithic N can be hard to maintain too, but if you are going to call the steps controllers then they will end up itty-bitty. My feeling here is to roll it up into another concept, such as a form or view, and not to try too hard at purity. The other approach is to put all of this navigation into the template along with the links. It won't be perfect and you may occasionally have to do a redirect, but this distributed control may work out easier. It feels as if it should be messy, but I have never had any trouble playing around with sites built like this.

    The FrontController is a nice clear pattern that everyone understands.

    I have tried three approaches so far at form handling when not being forced to use a library. The crudest is a sort of big C, simply having a form class like this...
    PHP Code:
    class Form {
        function 
    Form($command) { ... }
        function 
    paint($template) { .... }
        function 
    handle() { ... }

    At this level you create a form subclass for each action in the site. The result of the handle() method is the next page to go to. The handle() method is where it all happens and is rather all seeing, both validating data and directing the model. This system works very well on teh display side if you are using Widget classes to make up your form. The catch is that the Form classes are acting as top level application scripts here and so will get large if the application is complex. For small sites, where a unifying framework is overkill, this is still an easy option. I am not sure how easy it will be to refactor yourself out of this hole if the site then grows though.

    A definite improvement is the Validator. This separates the form stuff into a generic class which is visited by the application logic.
    PHP Code:
    class Form {
        function 
    Form($command) { ... }
        function 
    addWidget($widget) { ... }
        function 
    paint($template) { ... }
        function 
    getSubmitAction() { ... }
        function 
    handle($validator) { ... }
    }

    class 
    Validator {
        function 
    Validator() { ... }
        function 
    testField($name$value) { ... }
        function 
    isValid() { ... }

    The change in emphasis is that the Validators only are subclassed and the decisions are in the top level script. A lot of the generic validation is done with the widgets (code injection, etc) and so the Validators talk only to the model. If the form is valid then the client script decides what to do. It would be possible for the isValid() method to actually carry out the action rather than just validate it, but this seems to bloat it. At least it didn't work so well when I tried it. The main win with the visiting validators is less fiddly control code.

    The third method I mentioned above, where a template carries the names of the classes. There is no actual front controller script written as this is generated from the template itself. It removes the one to one corresponence between controller and view and I think this is what makes teh resulting code nice and short. This was an XSLT experiment and one I may ditch in favour of WACT, despite it's early promise, as I may just end up reinventing the wheel otherwise.

    I have already mentioned the idea of a presentation tier for sites with radically different interfaces. This is definitely looking at things from a higher level than MVC, or at least that's the impression I get from the comments so far. To me the presentation tier includes things like sessions, shopping baskets, SOAP invokers, personal preferences. Basically anything per-user and not common to complete changes of interfaces.

    Now something a bit more radical perhaps.

    Thinking about Jason's problem with the constantly changing model, how about if we could create the core business objects like this...
    PHP Code:
    class Person extends Type {
        function 
    Person() {
            
    $this->Type();
            
    $this->addField('name', new Text());
            
    $this->addOptionalField('age', new Number());
            
    $this->addAggregate('employer', new Party());
        }
        function &
    create($name$boss) {
            
    $instance = &parent::create();
            
    $instance->set('name'$name);
            
    $party = &$this->getAggregate('employer');
            
    $instance->set('employer'$party->findByName($boss));
            return 
    $instance;
        }
    }

    $broker = &new Person();
    $person = &$broker->create('Marcus''sin'); 
    My job would be alright if it wasn't for the wages.

    Supposing that the Type and Instance classes have the following interfaces...
    PHP Code:
    class Type {
        function 
    Type() { ... }
        function &
    create() { ... }
        function &
    find($query) { ... }
        function &
    findById($id) { ... }
        function 
    createQuery() { ... }
        function 
    writeSchema() { ... }
    }

    class 
    Instance {
        function 
    Instance(&$type) { ... }
        function 
    set($name$value) { ... }
        function 
    get($name) { ... }
        function 
    save() { ... }
        function 
    canSave() { ... }
        function 
    isSaved() { ... }
        function 
    paint() { ... }
        function 
    paintAsForm() { ... }

    With everything defined in the model, the form controller becomes completely generic. If the entry page of the site starts you at a top level object, say your Portal object, and the generic view can paint links and buttons for all the typical actions, then this could be the only script ever needed...
    PHP Code:
    <?php
        $session 
    = &SessionPool::findSession($_COOKIE);
        
    $broker = &new Portal();
        
    $portal = &$broker->create($session);
        
    $portal->paint();
    ?>
    This is not my idea, it is the "Naked Objects" way of looking at the world. A viewpoint that is very interesting.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #46
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Palo Alto
    Posts
    179
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think there is a world market for maybe five computers.
    - Thomas Watson, chairman of IBM, 1943.

  22. #47
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Captain Proton
    Marcus, I'm sorry, I was not meaning to be impolite to you or anyone else.
    That's OK, I was being a little tounge in cheek anyway .

    Quote Originally Posted by Captain Proton
    Believe it or not but I've been working on and off for one and a half years now on trying to create a flexible framework following (some kind of) MVC pattern, I've redesigned everything like 5 times, switched back to an another design, etc, and the solution I have now is flexible enough for my needs and I feel that it is 'elegant', enforces separation of concerns and is powerful.
    In these struggles, how did MVC help you come to a final solution? I am not being facetious here, I really honestly want to know how your thought processes went. So many of us have gone down the MVC route and either posted messages of confusion, or have given up with it and used normal OO factoring to resolve the issue. Why is it that some find it incredibly helpful, why others don't?

    Quote Originally Posted by Captain Proton
    What's in a name anyway. Just give the thing a name, and whether that's Controller, InputController, PageController or Action doesn't really matter to me, it's all the same.
    I think a good (bad) example is the ApplicationController. It is a fundamentally different thing to the PageController/FrontController and yet has a similar name. In fact I am not such a fan of Fowler's naming. Too many helpers, gateways, controllers and the like.

    Quote Originally Posted by Captain Proton
    Could you give an example of when an Action has to be filtered through an ApplicationController please?
    I can think of quite a few. One is a site that adapts to click-stream data. This could be marketing stuff, taking a specific path through a catalog depending on previous viewing habits, or simply to avoid repeated pages. A support system could be another. If the engineer has a waiting problem when she logs in, then this could be made her home page until dealt with. A "see once" page is another, such as terms and conditions guarding public a service or a login page.

    Primarily I found clickstream the biggest motivator for creating the Navigator class. I would be interested to hear other experiences though.

    Quote Originally Posted by Captain Proton
    I would also really like to see a brief, structured overview of the alternative pattern you are suggesting. I will also prepare one for the MVC pattern I am suggesting, so maybe we can compare the advantages and disadvantages, which is what this discussion is all about, isn't it?
    Well I could, but I kinda just did for Jochen's comments . Also I don't tend to tackle things from a framework point of view. I usually just code to the problem. This is mainly because I am doing fewer, but more complex, projects these days. You don't get so much advantage from frameworking these.

    I am always open to problems though .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  23. #48
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Alright, before I try to explain my thoughtprocess in developing this framework.. Like I said before, I've been working on it on and off, and the weeks before the last couple of days, have been an 'off' time. So over the last couple of days I have been doing some serious thinking again and there are still some problems with the approach. You know, when you are working on a small piece of the puzzle for so long, you sometimes forget to see the big picture.

    OK, here's what I can remember from the process

    Well, it all started with a CMS (who hasn't got one on their name). I had functions for each 'task' of my application (i.e. adding a user, editing a news article). Those functions contained both controller logic, sql code and code to generate HTML. I had developed a form class like QuickForm then, which I was fairly proud of at the time It did all I wanted to do, but it was one class that contained both the validation logic and code for generating HTML using Widget objects. The problem came when I started to work with a web designer who built his forms in a HTML template. I could no longer use my form class for validating the form, because it was tied so much to the HTML widgets. So I found out the hard way that I had to "separate my concerns" into different classes. I also did a lot of reading at that time, Martin Fowler still had drafts of his PoEAA book online at that time, I had bought the Design Patterns book, so I picked up some good ideas at that time.

    I also started to develop more OO at that time, and so I wanted to encapsulate the functions responsible for the user interface tasks of my CMS (adding, editing) into objects. And because of the above problem of not being able to use my form classes for forms in HTML templates, I also encapsulated the code that generated those forms ('the View'?) into a separate object. So by then, the code that interacted with the database to insert data was inside what you could call a controller. But of course you get tired of writing the same SQL over and over and having to change it in dozens of places just to add one new field. So then I began to read about DomainModel and DataMapper over at Martin Fowler's site and I started to implement that. I guess that is how my MVC-like framework was born.

    Then I encountered patterns like InterceptingFilter and I found that they provided an elegant way to fitting things like authentication into the framework. It seemed logical to think of authentication as an encapsulated process that takes part in something like a 'request processing pipeline', before the actual task that the user wanted to perform could be carried out. I also did not want to be tied to one method of authentication for the framework. FrontController and InterceptingFilter provided elegant and flexible ways to realise these things.

    So, I think I've described the actual problems that lead me to use an MVC-like framework. Perhaps MVC has worked for me, because I actually had design problems in my code that I tried to solve and found that they could be solved by the pattern. A good identification of the problem (which is what I had) is an important part of the solution. I can't really remember how much of the MVC-pattern I 'discovered' myself and how much of it I implemented after reading about it, but I do know that I haven't just applied it to my code without thinking about what problems it would solve.

    But like I said, over the past few days I am beginning to wonder if MVC as I see it is really such an ideal pattern for all PHP web applications. Subviews that require access to a data source are indeed an important problem, and this time I'm not just talking about multiple forms on one page. A good example of this is perhaps the front page of PHPNuke. Imagine it would have a MVC-like structure (probably not in a million years, but that's another story ). Think of a page that displays a news item. Because you don't want the View to access the data source directly, the controller for that page would load the news item from the data source and pass it on to the View. No problem there: the View does not care where the model information comes from. But on that same page, there are an infinite number of "cool" blocks that each also need access to a data source. But, where do they get their data from without making calls to the data model layer? Views should not care wheir their model data comes from, remember.. They can not have their own controller to load the data for them, because there should be only one controller per page (View), right? Apologies in advance for my sarcasm towards PHPNuke. Where would you put the code to load such data?

    For desktop applications, there is no problem like the above. In the desktop MVC pattern, as I would like to call it, the controller responds to user interaction with a view. In the web MVC pattern as I see it, the controller responds to a request, a request that does not have to be tied to a view, because of the stateless nature of the web. Perhaps that is a fundamental difference in the two patterns. Maybe we should think of the controller in the web MVC pattern more as a 'request handler' (ApplicationController?), I don't know.

    Lastcraft, I'd like to thank you for asking me to write about this thoughtprocess. It has really helped me to see the big picture and the problems that come along with it better. I also have some new ideas for a better defined pattern, more on that in another post perhaps

  24. #49
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Captain Proton
    Well, it all started with a CMS......but I do know that I haven't just applied it to my code without thinking about what problems it would solve.
    Interesting. I have believed for some time now that a good design comes from a well constrained problem, rather than any cleverness on the part of the designer.

    Quote Originally Posted by Captain Proton
    Subviews that require access to a data source are indeed an important problem, and this time I'm not just talking about multiple forms on one page.
    The system we are developing at the moment involves a portal like "project" view and has to aggregate many different sources. We haven't tackled this in detail yet (hence the XSLT prototypes) as we are developing the web services side at the moment. Somewhen in the coming year I am going to have a head on collision with it though .

    The only thing we have agreed is that we all want to start from scratch with the solution. We want to re-evolve with just this constraint.

    Quote Originally Posted by Captain Proton
    Lastcraft, I'd like to thank you for asking me to write about this thoughtprocess. It has really helped me to see the big picture and the problems that come along with it better. I also have some new ideas for a better defined pattern, more on that in another post perhaps
    I've learnt a lot here too, especially how others see MVC. What are your thoughts on the better defined pattern? I am a big fan of groping around on SitePoint publicly humiliating myself .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  25. #50
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    The system we are developing at the moment involves a portal like "project" view and has to aggregate many different sources. We haven't tackled this in detail yet (hence the XSLT prototypes) as we are developing the web services side at the moment. Somewhen in the coming year I am going to have a head on collision with it though .
    I'm sorry to ask such a dumb question in the middle of such a great topic, but what the heck is a portal? How does it relate to views?

    Just to throw my 2 cents in... The way that I use MVC is to use little MVC blocks. A login MVC block would contain an action (controller), a model (user) and a view (along with tempaltes). I also have an MVC "manager" (factory?) class that knows how to get the MVC block for me. So I just call $login =& MvcManager::build('login'); And from the I call (echo $login->execute() The login MVC block handles everything from that moment for itself. That way I can build a page, using my little MVC babies, and keep everything seperate. Which helps me organize things better. The factory class could also accept arguments that could be passedto the view or action or models etc...

    Lately I have been thinking about designing applications from the interface point of view. From the users perspective. I look at a web page and say, what do I see? A page with a header, a login box and list of products to the right. Then I start typing sudo code. $page =& new BasePage('title'); $page->addMvcBlock('login'); $page->addMvcBlock('productList'); And then in my page class I'll put those peices where they belong, err in the template. It's more fun using a 'higher' level of abstraction when designing (for me anyway). Using sude code from the start lets me design naturally. Not that I'm saying I know what I'm doing! I'm crawling out on a limb here.

    Also, I have been reading a lot on whether or not to add validation/form info to models. I really think that this is where a lot of my problems come from and have been seperating forms/validation and models until now. I can see how a model is very much related (web application models anyhow) to forms and validation. I mean when you look at a real-world model and say that it doesn't have anything to do with validation, it's not true. Should they really be seperate? Web applications are much different than standard desktop applications, and everyone knows that. Why not bend the rules a bit to make things work for the web? It's just different.

    If you use me as a model, you could do this:

    $me->eatFood('oyster');
    if( $me->save() )
    ... ... ... other stuff here

    I would say, 'No! I can't stand oysters!' and the save wouldn't happen. That's because I KNOW that I don't like oysters. Does this make sense? I can take care of myself. So, that's comparing a real-world model with a Object Oriented model. And a form is just a way to put add/change internal data. Of course I have a way for data to come in. For the classic person example, a person has particular properties, (name, age etc...) they also have actions (talk, sit, walk etc...) but also ways to make a desicion (a brain, thoughts etc...) and a way to take in information (eyes, ears). To me the brain is the validation (and the data storage, but a different part), and the ears and eyes are the form. So, it could be as easy as calling a particular model, and calling it's methods, and it takes care of itself. Now that would save me time. I know this is nothing new, but as an architecture it really works.

    Of course, it doesn't have to be that simple. YOu could break up your model into peices, and have a model controller, or model factory. It would know (config? class properties?) how to put the model together. Maybe the model would have validation classes, and a form builder class. But they would all know how things work, thanks to the models properties and methods.

    Wow, I hope this makes sense to someone.

    Matt


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
  •