SitePoint Sponsor

User Tag List

Page 1 of 6 12345 ... LastLast
Results 1 to 25 of 142

Hybrid View

  1. #1
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    MVCP - MVC missing a layer?

    An http request could maybe be seen as having two parts.

    (1) a "presentation request" - ie the page to serve up to the client (model and view)

    (2) a "processing request" - any tasks which do not output anything to the browser: form processing prior to building the "success" page/form redisplay, authentication, etc (added in controller)

    In addition to MV&C, I wonder if there should be an explicit "non-output-processes" layer? That feels more symmetrical, putting non-output-tasks on a par with model & view in the API. Quite often there are questions about where in the MVC model form-processing should go - maybe this would make it clearer.

    Any takers for MVCP?

  2. #2
    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)
    IMO that is just an action of the controller, and specifically one from which you would send a redirect to an action that would show a view (sucess, errors, etc.).
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  3. #3
    SitePoint Addict mr tinkles's Avatar
    Join Date
    Jan 2003
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    An http request could maybe be seen as having two parts.
    or many!

    but, a http request, is merely http request, or 1 part. http request.

  4. #4
    ********* 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 McGruff
    Any takers for MVCP?
    In three years of tackling these issues I have not once managed to understand how MVC applies to the web. I have read the Model-View-Presenter stuff as well (which seems closer to what is now called MVC, rather than the original Xerox-PARC stuff). Sadly, I am still none the wiser .

    I cannot resist tossing in my own half baked ideas to date...

    Firstly this has nothing to do with templates. The view may use templates or it may not. 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.

    This has nothing to do with handling user input either. We get a dash of input before the script even gets run, but after that human intervention (except the stop button) is impossible. It is basically a batch process. To make matters worse the chosen script and the incoming data don't necessarily match up. We have to fix this to match the view with the data. After that we are locked into some kind of TransactionScript. The front controller gets around this by having only one script as an entry point.

    The model is not the same as the database. Because PHP starts empty on every request, only persistent information and network accessable information is available. This makes the model much more clearly defined than in, say, Java. However, we can cloud the issue by saving sessions out to the database. Session information is nothing to do with the model though, and should be kept conceptually separate. Thus the database may be involved in the controller/view system or the model.

    Simplistically it strikes me that the "controller" in web MVC is actually just internal logic to stitch together the incoming arguments to the script that will run them. It has absolutely nothing to do with the controller in GUI apps. Except, there is more to it than that.

    The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. Because in PHP we are always completing the last action and offering up the next, we are actually doing two half jobs. This means that the real application control, the real top level meat, occours half way between each script. A good way of exposing it is to split all top level scripts into *_display.php and *_handler.php in a typical application. You suddenly find that you need a bit of extra logic either at the end of the handler script, or the start of the display script to select the next display. Hardly surprising that this very important top level logic gets buried away and becomes difficult to modify. I wouldn't call the class that deals with this logic a "controller". More of a "navigator".

    The real killer is that different parts of the app. need different styles. A library site needs static URLs with multiple views. A bulletin board is highly dynamic form based environment and would favour a FrontController regime. A shopping cart needs a "navigator" type of controller as this is more of a "Wizard" interface. Trying to fit all of these into MVC strikes me as way too difficult.

    And I still don't understand MVC...

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

  5. #5
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very interesting.

    MVC RIP, I guess

  6. #6
    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
    I cannot resist tossing in my own half baked ideas to date...
    Welcome to the club!
    Firstly this has nothing to do with templates. The view may use templates or it may not.
    Heavy nodding up to here.
    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).
    This has nothing to do with handling user input either. We get a dash of input before the script even gets run, but after that human intervention (except the stop button) is impossible. It is basically a batch process.
    So is any GUI application. The application sits idle waiting for a widget being fiddled with, then it does whatever the user said he wanted. Although it may be very fast, the user usually has to wait until that piece of processing is done. He can put more events into the execution queue, but only rarely can he really intervene in a running piece of logic.
    To make matters worse the chosen script and the incoming data don't necessarily match up. We have to fix this to match the view with the data. After that we are locked into some kind of TransactionScript. The front controller gets around this by having only one script as an entry point.
    Chosing the correct view is the job of the Controller (which can be a Page Controller, Front Controller, or any other unnamed piece of code). The business logic that gets run before this happens can be anything from a Transaction Script to some Commands on a Domain Model.
    The model is not the same as the database. Because PHP starts empty on every request, only persistent information and network accessable information is available.
    In most applications the model will rely on some form of persistent data, be it from flat files or a database, because PHP applications do not retain their state between requests.
    However, we can cloud the issue by saving sessions out to the database. Session information is nothing to do with the model though, and should be kept conceptually separate. Thus the database may be involved in the controller/view system or the model.
    Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.
    Simplistically it strikes me that the "controller" in web MVC is actually just internal logic to stitch together the incoming arguments to the script that will run them. It has absolutely nothing to do with the controller in GUI apps.
    Beg to differ again. The controller in a GUI application receives user input, decides what domain objects need to be instantiated and what commands to be run on them, and then passes the results on to the GUI for display. Same thing.
    The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. (...) I wouldn't call the class that deals with this logic a "controller". More of a "navigator".
    This is one point that causes a lot of confusion about MVC: The piece that you are talking about is what Fowler calls an "Application Controller": A layer that controls the flow or sequence of screens that are presented to the user, to be used whenever it gets more complex that one view for one controller. He also says that it has nothing to do with the "Controller" in MVC which he prefers to call "Input Controller". I think this distinction serves a lot to clarify the MVC.
    The real killer is that different parts of the app. need different styles. A library site needs static URLs with multiple views. A bulletin board is highly dynamic form based environment and would favour a FrontController regime. A shopping cart needs a "navigator" type of controller as this is more of a "Wizard" interface.
    Again, see the above distinction: Where the Front Controller would take the part of MVC's Input Controller, the "Navigator" role is taken by an Application Controller. The two can happily coexist. In my applications the Application Controller is actually used by the Front Controller. After the domain logic is run, control is handed over to the Application Controller who decides what view should be shown next. Before I read PoEAA, I called this part the "Workflow Engine".
    Trying to fit all of these into MVC strikes me as way too difficult.
    MVC is all about separation of responsibilities. Once you have a clear view of the roles in MVC, it's quite easy to find the right place for each piece of behaviour you need. It helps if you remind yourself that the three letters stand for parts of the application, not individual classes. There will rarely be only one "Controller" or "View" class. The Controller of our last app consisted of almost 20 classes working together to fill the roll.

    So there's plenty of space to fit all these things into.

    And I still don't understand MVC...
    I don't claim I do either, but from looking at it I've gleaned a way to build systems that solve my problems, which is what patterns are all about, after all...
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  7. #7
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ZangBunny
    Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.
    I agree with ZangBunny on this point. I often bind an array key of the $_SESSION array to a class var in some of my model classes. This effectivly makes the class a singlegton from the perspecitve of that data, as well as allowing the data to persist for the session. Examples of the kinds of situations where I do this include user validation (where the User class maintains the authenticated user id in the session) and Form Wizard type classes where I want to remember user inputs( in case validation fails or the user goes "back" to a form, etc.). (BTW, I make these Form Wizard type classes as models instead of controller objects because of my perspective that $_SESSION data represents a persistant data store, and data stores should be accessed only through the model layer in MVC, if I had a different opinion on the session, I guess I might argue that these Form Wizard classes relate only to $_REQUEST data and should be in the controller instead )
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

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

    Ok, if you are A-team I'll be B-team...

    Quote Originally Posted by ZangBunny
    It could, but then it wouldn't belong in an MVC architecture.
    Quite. I wasn't onto the MVC bit at that point. The custom "smart" tag approach is my current favourite way to do things for complex applications. I think it is a valid pattern in it's own right, a sort of template/tag/model pattern, that is rarely considered. Anyway, digression over.

    Quote Originally Posted by ZangBunny
    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).
    Why? This made sense in the Smalltalk environment which dealt with much more primitive situations. 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.

    Quote Originally Posted by ZangBunny
    So is any GUI application. The application sits idle waiting for a widget being fiddled with, then it does whatever the user said he wanted. Although it may be very fast, the user usually has to wait until that piece of processing is done. He can put more events into the execution queue, but only rarely can he really intervene in a running piece of logic.
    It's not really the same. Firstly there is the scale question. With a GUI we are usually dealing with very fine grained operations that would be tedious over a network. Secondly, long processes can be handled concurrently and can be cancelled in response to the constantly updating view. With the web we usually only get to see things after they are complete.

    The real difference though is that the controllers in a GUI app. both present the button and hand off the results of the click. 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. This adds an enormous amount of complication to what would otherwise be a simple piece of code. That extra rebuilding step is the tricky bit and the one that is not addressed in GUI MVC. I think this is why MVC is not so helpful.

    Quote Originally Posted by ZangBunny
    The business logic that gets run before this happens can be anything from a Transaction Script to some Commands on a Domain Model.
    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. Otherwise you have to introduce more objects. 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.

    Quote Originally Posted by ZangBunny
    Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.
    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.

    Quote Originally Posted by ZangBunny
    Beg to differ again...
    So do I . I was leading to the "Presenter" part of the argument.

    Quote Originally Posted by ZangBunny
    The piece that you are talking about is what Fowler calls an "Application Controller": A layer that controls the flow or sequence of screens that are presented to the user, to be used whenever it gets more complex that one view for one controller.
    Absolutely. I wanted to avoid the Fowler terminology because he uses the word "controller" for everything. I wanted to avoid "Presenter" because of it's previous use in Smalltalk frameworks. Thus I went for "Navigator", but yes that is the core idea. If you call it a controller though, then MVC has to become MVCC.

    Quote Originally Posted by ZangBunny
    The two can happily coexist. In my applications the Application Controller is actually used by the Front Controller. After the domain logic is run, control is handed over to the Application Controller who decides what view should be shown next. Before I read PoEAA, I called this part the "Workflow Engine".
    Me too . I called mine "SiteMap".

    Quote Originally Posted by ZangBunny
    So there's plenty of space to fit all these things into.
    I think that this is the problem. The view and model are easy. Calling everything left over a "controller" doesn't really help. In fact it just seems to slow everybody down. FrontController, TemplateEngine, CustomTag, SiteMap/WorkflowEngine (I won't use ApplicationController within this thread ) and TransactionScript are very clear and powerful design decisions.

    The debates on the PHPPatterns site about the FrontController v. the PageController was easy to follow and advanced the issue. The endless MVC discussions don't seem to go anywhere. Even Fowler devotes only a half page to it in the whole book.

    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.

    Quote Originally Posted by ZangBunny
    ...I've gleaned a way to build systems that solve my problems, which is what patterns are all about, after all...
    It certainly says in no uncertain terms to separate out the M and the V. I agree this is very helpful.

    Sorry about the length of this reply Jochen , It's just that I feel we are getting somewhere .

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

  9. #9
    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

  10. #10
    ********* 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

  11. #11
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very good post there lastcraft. You keep amasing me.
    .: raz0
    .: email: raz0[at]worldonline[dot]dk
    .: webpage: http://raz0.zalon.dk/

  12. #12
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Lastcraft, always a Prophet. You got my own gears turning as well...

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

    Amazing. I can spout junk off the top of my head and admit I don't even understand the problem, and people love me . Cool .

    Guys, I really don't know what I am talking about here. I am probably more confused than anyone and all I see is problems and no answers. It needs a Jason or a Jeff to sort out my mess of a post.

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

  14. #14
    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)
    Too busy putting the final touches on the presentations for the cruise presentations to go in depth at the moment, but your comment and the responses remined me of two quotes:
    Quote Originally Posted by Socrates (as best I can remember)
    True knowledge consists of knowing that you know nothing.
    and
    Quote Originally Posted by Paraphrased from G.I. Joe
    Knowing what questions to ask is half the battle.


    Can I recommend downloading PHP|Architects free (with registration) issue that has my "Introduction to MVC using PHP" article and "Industrial Strength MVC" for some of my opinions on MVC.

    Regards
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  15. #15
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've always thought that MVP was all ******** anyways

    --EDIT--

    I've been sensored...

  16. #16
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For those of you who haven't read it yet: Beyond MVC: A New Look at the Servlet Infrastructure.

    N. Alex Rupp makes a good case against using MVC outside it's original context (applications with user interfaces). The only thing I'm not entirely happy about is the alternative application 'structure' he suggests on page 3: it's possible to perform an Action that doesn't use any DataSource or WorkFlow components, so mentioning these the explicitely may suggest to some people that they must be included for each possible Action.

    To be honest, I find it a bit surprising that so many people on these forums are still trying to use MVC, when the pattern raises so many questions about application structure and layering, the placement of concerns, etc. Just look at all the threads about the location of SQL queries, form validation, etcetera. And as far as I can tell, most (if not all) of these problems still have to be solved by the people who originally submitted them, so it doesn't look like the MVC pattern is really solving any problems...

    Maybe it would help if we view our PHP scripts as web services instead of web applications: an application is usually associated with direct user interaction, and this direct interaction simply doesn't exist with PHP scripts (unless you're working on a PHP-GTK application, of course).

    I tried to use MVC for my PHP framework for some time, and finally decided to move away from it a couple of months ago; it just didn't solve any of the problems I had, and caused me a lot of headaches. Nowadays I'm working with the idea that the total of the client software, server software, and the scripts running on the server all form a single service to a user, where each type of software forms a separate layer, which provides a specific subservice... (basically my own interpretation/visualization of the HTTP protocol).

    I'll post a longer description if anyone is interested, and when I have a bit more time.

  17. #17
    Mal Reynolds Mandibal's Avatar
    Join Date
    Aug 2003
    Location
    Columbus
    Posts
    718
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Isnt the the idea of MVC supposed to promote modularity in applications allowing them to use multiple interfaces? I'm not sure I'm wholly disagreeing with all of Marcus' points but I think if you truly seperate the View in your application (even with PHP as your language [and this is where i may be wrong]) you should be able to use a web interface, a gui or even the command line right? This is MVC from my understanding. And this would apply to the web.
    Erh

  18. #18
    ********* 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 Mandibal
    ...but I think if you truly seperate the View in your application ... you should be able to use a web interface, a gui or even the command line right?
    Absolutely . I have no trouble separating the view from the model. All you have to do is to try to imagine a web version, web services version and command line version. Anything common to all ends up in the model and so a refactoring we go. This pattern used to have a name too - Document/View. This was the pattern adopted for Windows apps. because the old Smalltalk controller functionality, mouse clicks and the like, was now handled by the Windows OS itself. The old controller had very little purpose.

    It's the controller that is the problem.

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

  19. #19
    Mal Reynolds Mandibal's Avatar
    Join Date
    Aug 2003
    Location
    Columbus
    Posts
    718
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Azmo brings up some good points as well. Still standing by my previous post and interpretation of MVC but...Maybe a different view is called for which consists of Presentation layer,Domain/Business logic, Business/Data Model. This is from PoEAA. (mostly. Didnt have it in front of me to reference but I think its right). This seems like a better way to look at applications (particularly web) than just MVC.
    Erh

  20. #20
    SitePoint Zealot
    Join Date
    May 2001
    Posts
    193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm interested in seeing your aprroach
    I'll post a longer description if anyone is interested, and when I have a bit more time.

  21. #21
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Azmo: I too would be very interested what your "post-MVC" world looks like.

    While our framework at work is far from a "true" MVC model, I have found that many of the principles that I learned through MVC do apply very well on the web. Most notable of which is probably to separate a view, and more specificially, a "TemplateView" kinda layer. For us, following MVC as a loose guideline (more than as a Bible) has been helpful in more than one ocasion. I still like the principle of a "controller" page as your main entry point and switchboard.

    By the same token, violations of some MVC principles that some people hold very dear, have also benefited us greatly, and I plan to continue doing so as long as it makes sense. For a quick example: most MVC uber-zealots would probably tell you that your views have to be 100% "dumb" and in some cases should only accept data through a "push" methodology. I wholeheartedly disagree with this principle, and I foresee a better MVC wherever you add some more responsibilities and capabilities to your templates in the way of components (ala WACT) or other declarative syntax. Its the only good thing that Cold Fusion ever brought to web development: clever templates

  22. #22
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some of the quizzicalness of this thread sounds to me like noone has read PoEAA around here. If you did and you still need help, I'll be happy to play the A-Team. (If you didn't and are too stingy to buy the book, you're on your own. ;-))
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  23. #23
    ********* 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
    If you did and you still need help, I'll be happy to play the A-Team.
    I'll take you up on that . Please explain it all...

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

  24. #24
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This could be interesting huh ? ... Enlighten us all ZannyBunny

  25. #25
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Palo Alto
    Posts
    179
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd definitely like to hear ZB's comments, but before he chimes in, I'll add my clutter to the mix. I've seen a few common problems with PHP developers and MVC (and keep in mind that I'm not talking about the contributors to this discussion, rather about common issues I've seen over the last year or so):
    1. An almost complete lack of understanding of what MVC is and isn't. There seems to be a push to implement "everything Java" in PHP, and I think that's a mistake. PHP is not now and hopefully never will be Java. I've said it before and I'll say it again: we'd all be better off applying this effort to PHP innovation, not Java duplication. (Which is not to say some Java practices aren't applicable -- many are.) MVC can be useful in PHP web applications, imo, but I get the impression that a lot of developers are tackling it because it's the Latest Buzzword, and they're not taking the time to learn what it is. MVC is a pattern used to separate model from presentation and controller from view, to use Fowler's description. I won't go further because it would all just be more repeat of PoEAA, Pragmatic Programmer, or Core J2EE Patterns (all of which I highly recommend).
    2. An almost compete lack of understanding of when and why to use a Front Controller (which I think most developers seem to think is the whole of MVC). There's almost no need for it (imo) in smaller web applications, because you can do an effective job of separation without it, and FC always complicates the code. In smaller web apps, the Page Controller does the trick nicely.
    3. For those that do seem to understand the what and when, the most common stumbling block I've seen is the concept of a single controller handling all communication between objects (always makes me think of the multi-armed mail sorter in MiB2). I'm exaggerating, but only a little. From The Pragmatic Programmer:
      Each of these views may have its own controller.
      From PoEAA:
      The classic example of why you'd want to separate them is to support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies [Gang of Four] for the view.
      Many developers seem limited to only the Front Controller, and they end up attempting to force it to control the entire application, eventually producing spaghetti code. The FC is a router or handler that should appropriately dispatch requests to the proper controller objects, what Fowler calls commands:
      Remember that both the handler and the commands are part of the controller. As a result the commands can (and should) choose which view to use for the response.
      And here I've gone and done it -- I'm down to just quoting books after all. <sigh> I suppose I should shut up now.
    I think there is a world market for maybe five computers.
    - Thomas Watson, chairman of IBM, 1943.


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
  •