SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 56

Thread: MVC confusion

  1. #26
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oppss, sorry as a slight mis-understanding

    What I actually meant was that we are now using XmlHttpRequest and related technologies, which from my sense, amounts to be about the same thing. Rich media I think the term is loosely refered to?

  2. #27
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Oppss, sorry as a slight mis-understanding

    What I actually meant was that we are now using XmlHttpRequest and related technologies, which from my sense, amounts to be about the same thing. Rich media I think the term is loosely refered to?
    I'm still not sure that I understand you. XmlHttpRequest is nothing more than a HTTP client inside a browser, accessible from the scripting scope. It's nothing new -- I have used it half a decade ago -- and the format of the data it gives access to -- plain text basically -- is even older. What exactly do you mean by "rich media"?

  3. #28
    SitePoint Enthusiast Zeldinha's Avatar
    Join Date
    Sep 2004
    Location
    Barcelona [Spain]
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    That is true, you need to implement MVC for each template fragment/view, but in all honesty, most of the MVCs are reusable, and you really (for me anyways) only have the one MVC per page request anyways, such as listing all products, adding a new product, etc.
    Hmmm... I recently came into this problem, I had a list of articles, but these articles had a list of related comments as well (and the comments had some other relationships). Shouldn't that "sub list" of comments go through MVC, too? Just as Beris said.

    I like the MVC concept, sounds really nice, but then I get to points such as this and it all gets a tad too complex. And I don't think it's a very specific case, but quite common

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Shouldn't that "sub list" of comments go through MVC, too?
    Just as much as a View is composed of fragments, I suspect that MVC can be composed of fragments as well?

    WACT may support this I think, in that you have a parent action (Articles) and child actions (Comments), but I've not looked into this yet, so this is shaky ground.

    Rich media to my mind is something that the user can interact with in (near) real time, but using XmlHttpRequest and it's related technologies was what I actually meant originally, I just put it across the wrong way, that's all

  5. #30
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Amersfoort, the Netherlands
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Zeldinha
    I like the MVC concept, sounds really nice, but then I get to points such as this and it all gets a tad too complex. And I don't think it's a very specific case, but quite common :S
    Functionality often comes with complexity. Take the regular expressions and mod_rewrite for example, they're awesomely powerful but they take a while to figure out. The same goes for MVC and many other design patterns. I think the purpose of this specific forum is to figure out how to implement and understand the patterns at hand.

    @ Dr Livingston I've see you're pretty fond of the way WACT works, no? I've browsed through the site in search for some sample code to learn from, but couldn't find much. Should I just start bending my head around the entire framework source? What I'm particularly interested in is how WACT handles composites, authentication (and other filters) and data access...

  6. #31
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    This in it's self isn't a bad thing, as the topic is then open for discussion nearly all the time, and everyone has their own ideas, etc to contribute, so who knows, maybe eventually, PHP will have something solid based on MVC?
    http://www.amazon.com/exec/obidos/AS...246252-0740621

    With your other comments I totally agree though
    Hello World

  7. #32
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Amersfoort, the Netherlands
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Which design patterns would come into play when creating such a site? Can somebody list the most essential ones and describe their task? I've heard Composite and Visitor being mentioned, along with Observer and of course MVC, but I have no clue which does what in the process
    Last edited by oscar alexander; May 24, 2005 at 01:49.

  8. #33
    SitePoint Enthusiast Zeldinha's Avatar
    Join Date
    Sep 2004
    Location
    Barcelona [Spain]
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oscar alexander
    Functionality often comes with complexity. Take the regular expressions and mod_rewrite for example, they're awesomely powerful but they take a while to figure out. The same goes for MVC and many other design patterns. I think the purpose of this specific forum is to figure out how to implement and understand the patterns at hand.
    The thing is, regexps tend to finally simplify things that otherwise would be too long, complicated, hard to achieve. But I'm still in doubt if the same is possible with MVC in such environments where you would need to chain lots of sub MVCs. I'm still struggling a bit to find the "easy way" with it. But well, I'm no OOP expert so I guess it's normal

  9. #34
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Amersfoort, the Netherlands
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On a side note: Here's a nice online GoF overview I found linked in comments at phpPatterns.com:

    http://home.earthlink.net/~huston2/dp/patterns.html

    Also, I was wondering if the below scheme would be a "smart" approach for a controller system. The Front Controller fetches the "view" parameter and checks if the "view" Page Controller exists. If so, includes the Page Controller (group.php), which checks if "action" is supported. If <action>.php exists (Controller) the controller is instantiated and the view is rendered. Please let me know if this makes sense and if I have my terminology right


    HTML Code:
    		$_GET[‘view’]	$_GET[‘action’]
    
    index.php checks if Page Controller exists or uses default:
    
    /lib/views/	group.php
    
    group.php checks if Controller exists or uses default:
    
    /lib/views/	group/		list.php
    /lib/views/	group/		new.php
    
    group.php instantiates Controller based on "action" which sets the Model for this "view":
    
    /lib/classes/	group/		groupModel.php
    Last edited by oscar alexander; May 25, 2005 at 12:47.

  10. #35
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've said it before, and I'll say it again.

    The apparent obsession on this forum of coding TO patterns is missing the entire point of patterns.

    Patterns evolve FROM code. Code doesn't evolve from patterns.


    If a given pattern, such as the much-maligned MVC pattern, produces so much confusion and debate, there's a good chance that it has been misplaced. Perhaps the intent is good, but the atmosphere, as mentioned above, is not.

    If you code your application, and then see an MVC framework evolving from it, that's fantastic.

    But if you spend so much time worrying about "complying" to the given MVC definition of the week, your site will never see the light of day.


    That being said, I have developed an MVC-reminiscent framework that works well.

    All this talk about View and the complexity surrounding choosing a View is not necessary. My Controller chooses the View. One single View. It chooses this based on the request and the filters. Once the View is chosen, my Controller chooses a Model that will fulfill the requirements of my View.

    I don't think it needs to be more complex than that.

  11. #36
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Patterns evolve FROM code. Code doesn't evolve from patterns.
    Not sure about either of those. Patterns are things that experienced programmers have found are applicable over and over. They are also a language to talke about these things. If you are new to patterns then it is good advice to code first. As you become more experienced with patterns their meanings and inter-relationships can provide insight and direction.
    If a given pattern, such as the much-maligned MVC pattern, produces so much confusion and debate, there's a good chance that it has been misplaced.
    I don't think "misplaced" is it. As I have said before, the problem with MVC is not the ideas. It is that it is asking programmers to make one of the most important leaps in programming. That leap is separating the Model from the Presentation. It is unfortunately a difficult thing to do and one with slim payoffs at first. But let's face it, an independent Model layer is the real struggle here for programmers new to MVC.

    It is interesting that those new to MVC quibble about Model/Presentation separation. Whereas familiar with MVC quibble about View/Controller separation. That should say something there.
    Christopher

  12. #37
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Viflux makes one important point here, when he says:
    Quote Originally Posted by Viflux
    But if you spend so much time worrying about "complying" to the given MVC definition of the week, your site will never see the light of day.
    The patterns are intended to solve the problems, not to become problems themselves. The idea is that when you identify a common problem while making an application, and there is an appropriate pattern which solves it, you apply the pattern.

    It is apparently a common habit among the programmers to find a solution first and then ask for help about applying that solution, instead of asking for a solution. The same is with patterns, and an extremely severe case of patternitis appears when people are looking for ways to incorporate patterns that work in some platforms/languages, but not on others.

    Each technology has its ups and downs, and patterns are here to resolve those downs, not to become ones themselves.

  13. #38
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Not sure about either of those. Patterns are things that experienced programmers have found are applicable over and over. They are also a language to talke about these things. If you are new to patterns then it is good advice to code first. As you become more experienced with patterns their meanings and inter-relationships can provide insight and direction.
    While you are correct about patterns providing insight and direction, they should not be the basis for the project.

    You don't go into your initial design planning phases, before writing any code, and say that you're going to use a Visitor patter, Decorator pattern, Factory pattern, etc...

    Well, maybe you do, but I don't. In my experience, patterns provide an effective way of refactoring your code around stumbling blocks. We implement patterns when they are useful for optimization purposes, not for the sake of using the pattern (which is what I feel happens all too often on these forums).


    Edit - My apologies to the thread starter for steering the thread off topic.

  14. #39
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, maybe you do, but I don't. In my experience, patterns provide an effective way of refactoring your code around stumbling blocks. We implement patterns when they are useful for optimization purposes, not for the sake of using the pattern (which is what I feel happens all too often on these forums).
    I actually agree with you. My point was not to contradict what you were saying, but as a lead-in to all the supposed confusion around MVC. It is conceptionally simpler that most patterns. But it describes an architecture for a more experienced programmer. Separating (and keeping separate) the Model is damn hard work. If you currently have a site build from a bunch of Transaction Scripts, moving toward MVC can be very painful for an inexperienced programmer. But, once you crest the ridge and start rolling down the other side, each dependency removed just reduces friction.
    Christopher

  15. #40
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Viflux
    All this talk about View and the complexity surrounding choosing a View is not necessary. My Controller chooses the View. One single View. It chooses this based on the request and the filters. Once the View is chosen, my Controller chooses a Model that will fulfill the requirements of my View.

    I don't think it needs to be more complex than that.
    It unfortunately does need to be more complex than that when you're displaying data that comes from different sources. Take the home page of sitepoint, which features selected articles, blogs, newsletters, forum posts, and navigation links, which are all pulled from different tables; clearly there's more than one model, and while you could handle them all with a single controller and view, this isn't the best approach if you want your code to be easily reusable. Hence the need for a more complete but more complex solution.

    Quote Originally Posted by arborint
    As I have said before, the problem with MVC is not the ideas...
    Quite right; the problem with MVC, and patterns in general, is that it's an approach for solving a problem, and not a solution in and of itself. As concepts go, they are quite abstract, and can be difficult to grasp without being well explained, and having an implementation to look at. In my case, MVC was pretty easy to understand after I read the article about it on phpPatterns and played around with the code, but such ressources seem to be hard to find; a search for CompositeView on google turns up a bunch of explanation about what it is, but none about how to go about implementing it.

  16. #41
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the problem with MVC, and patterns in general, is that it's an approach for solving a problem, and not a solution in and of itself.
    Actually I think they are solutions in and of themselves (and in combination). My struggle with patterns is that they are sophisticated solutions by brilliant programmers and I am often not at an experience level to fully understand or appreciate all that they communicate. Or as with MVC, I get what it communicates, it is just hard to achieve.
    Christopher

  17. #42
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Amersfoort, the Netherlands
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's amazing how soon topics start drifting here

    Could someone still reply to post #34 please?

  18. #43
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by 33degrees:
    It unfortunately does need to be more complex than that when you're displaying data that comes from different sources. Take the home page of sitepoint, which features selected articles, blogs, newsletters, forum posts, and navigation links, which are all pulled from different tables; clearly there's more than one model, and while you could handle them all with a single controller and view, this isn't the best approach if you want your code to be easily reusable. Hence the need for a more complete but more complex solution.
    Not every problem needs a complex solution. Even not a project like sitepoint. The question i was asking me; should i use a complex system which follows 100% the mvc pattern to solve such problems or should i use a not 100% mvc structure which dosent cause to me heavy headaches. My problem with mvc is how the controller and the view are coupled to (or interact with) the model. Thats because is so complex to solve such problems like sitepoint.

  19. #44
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oscar alexander
    ...post #34 please?
    PageControllers & FrontControllers are input controllers so strictly speaking a FrontController doesn't hand over to a PageController - although it could be to something very similar. There are also application controllers. If there is more than one possible response to a request, an application controller decides which it should be. A FrontController identifies the type of the request and maps that to an application controller (one-to-one). An application controller maps the request to a response (one-to-many).

    You shouldn't need to pass a $view parameter around. That's part of the request-to-response mapping inside a controller. In any case you can't know in advance which response (or view) will be made to the request, except in very simple cases.

  20. #45
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by atu
    Not every problem needs a complex solution.
    I wouldn't say that MVC is complex. At least, it doesn't require complex code. Some quite complex discussions occur on the fine points of what goes where, of course.

    I don't want to be anti-learning but I wonder if MVC is best avoided until you feel you've got a good understanding of the standard presentation/domain /data layering. It is a good design pattern but it's also something of a buzzword. If an app is touted as MVC I don't feel that's really telling me much. Half the time they aren't even MVC but everybody feels that's some kind of standard they have to aspire to, and call it MVC anyway.

    I wish something more useful like unit testing was the buzzword de jour with programmers in a mad rush to prove their prowess with a testing framework. Now that would be nice to see.

  21. #46
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't want to be anti-learning but I wonder if MVC is best avoided until you feel you've got a good understanding of the standard presentation/domain /data layering.
    Forget every thing about mvc and try to design an application which is structured on separated layers. How much does it differs from mvc? And is there a natural way that every design leads into mvc? It would be interesting to see the different approaches.

  22. #47
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not forget all about it. It's something you do need to learn about eventually but the basic presentation/etc.. layering should come first.

    The really important thing is to separate presentation and domain. MVC finesses that by splitting the presentation layer into controller and view. A design could easily evolve into MVC almost by accident if you tend to write lean classes which do just one thing. Controllers (receiving input, making decisions, issuing instructions) don't have a lot in common with views (gathering and formatting data) after all

  23. #48
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think some people glue to much to this mvc pattern and finaly lose the pedals while the complexity of the problems to solve increase.

    I'm shure that most designs leads into some kind of a model, view and controller but may the workflow and the definition of the job of each part and how they communicate to each other are different.

  24. #49
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't go into your initial design planning phases, before writing any code, and say that you're going to use a Visitor patter, Decorator pattern, Factory pattern, etc...
    But further into the design phase, once you have experience with using design patterns, you'll notice that from the design, you'll see a pattern or two starting to emerge from that design.

    So it's the design of your software application that speaks for it's self yes?

  25. #50
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by atu
    Not every problem needs a complex solution. Even not a project like sitepoint. The question i was asking me; should i use a complex system which follows 100% the mvc pattern to solve such problems or should i use a not 100% mvc structure which dosent cause to me heavy headaches.
    MVC isn't inherently complex; I've done small projects that use MVC with less than 1000 lines of code. In fact, it's probably having used MVC in small projects that has enabled me to tackle using it for more complex projects. If using MVC is causing you headaches, maybe it's because you're trying to apply it to a relatively complex problem without fully understanding how the pattern is supposed to work?

    My problem with mvc is how the controller and the view are coupled to (or interact with) the model.
    Generally, I've seen two approaches; either the controller extracts data from the model and pushes it to the view, or the controller passes the model to the view, which pulls the data it needs. I prefer the second approach, because I find it more efficient to iterate over a recordset rather than put the whole thing in an array and pass that over.


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
  •