SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 72 of 72
  1. #51
    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)
    In a nutshell, my view of MVC boils down to this:

    * Model - domain logic (data persistance, rules, domain specific validation...)
    * View - presentation logic (how to structure data from the Model for viewing)
    * Controller - application flow (http request handling, action/view dispatching)

    I usually end up having the controller interpret the HTTP request to determine what should be done. This might include actions which call methods of Models which update underlying persistent data (in such cases, I usually redirect to a view "mode"). My controllers usually then select a particular View to display. I have "Fowleresk" ViewHelper classes which query the Model classes and load template variable. While I generally name these classes "view", you could concieve of them as still belonging to the controller. The template engine the performs the bulk of the work formatting the Model data for presentation and output to the user.

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

  2. #52
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE

    Anyone willing to elaborate on whether the controller should use the model to say fetch(!, not manipulate) some data from the datasource and then pass the model to the view or whether the view should use the model to fetch the data. Does it matter much? WHat are the Pros and Cons?

    Too bad Fowler does not say anything about that in PoEAA. He simply states that the controller is responsible for manipulating the model. That's alright. But should fetching some data from the datasource also be considered as manipulating the model? Sounds like it does it not?
    There's no doubt in my mind that fetching data from a datasource is manipulation; not in the sense that the data from the datasource is modified, but in the sense that the state of the model is changed. Basically, It's a command that's given to the model, based on a decision regarding the request, and that's why it should be done by the controller.

    As for benefits, one of the main ones for me is that by having the controller do the loading, you can pick a view to display depending on how the loading went, like showing either a success or an error page. With the loading command inside the view, what happens when loading fails?

    Quote Originally Posted by kyberfabrikken
    Re: DispatcherView
    so is mine, but it took me some time to swallow it, since for simple pages it gives the impression of not being "proper" MVC as the V and C aren't seperated.
    I actually had a look at the pattern online, and it isn't what I thought it was.... In my current system, the controller passes the model to a class that pulls the data from model, then pushes it to the template. I'm not sure exactly what this would be called, maybe a TemplateView with helpers?

    In the long run, I plan on moving towards some kind of component based template system using declarative syntax; but that's still a ways off

    Quote Originally Posted by Viflux
    Well, as of now, it can use a database, text file or XML file as the data source.

    I don't actually create an XML file, I just pass around XML stored in a variable. No different than storing all your content in a variable, in an unorganized state.
    I shouldn't have used to word 'file', I just meant that having big chunk of xml data in memory could be a performance issue?

  3. #53
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    There's no doubt in my mind that fetching data from a datasource is manipulation; not in the sense that the data from the datasource is modified, but in the sense that the state of the model is changed. Basically, It's a command that's given to the model, based on a decision regarding the request, and that's why it should be done by the controller.
    Alright, agreed.

  4. #54
    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 33degrees
    With the [data] loading command inside the view, what happens when loading fails?
    A ChainOfResponsibility can be a good pattern for this. An http request is simply passed along the chain until an object is found which can handle the request. Decision-making can be factored out of the 'handlers' completely, giving you the VC split.

    A handler (which could be a view) could simply return true if it succeeded, or nothing if not (for example if it can't get hold of the data it needs).

    It's also quite a flexible system in that you can drop loosely-coupled handlers in and out of a chain easily, for example to require authentication/authorisation for a particular request.

  5. #55
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm, I still wonder how to detect when one or several actions should be executed. As I've said earlier, one way to solve the problem is to do the deciding on the application controller level with a (large) switch-statement. E.g the user does a request on [www.example.com/index.php?section=something&action=anything]
    The appropriate controller gets initialized and the switch-statement decides which actions should be executed based on $_GET['action'].
    ChainOfResponsibility is one way to improve the design (remove the switch), although, I'm not convinced, since I will have to create several classes for the handles in the chain.

    Has anyone got a better solution? :/

  6. #56
    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 Overunner
    I'm not convinced, since I will have to create several classes for the handles in the chain.
    I'd see that as a good thing: one class trying to do lots of different things gets refactored into smaller, more focussed classes. All that's left behind is some control logic - which also comes into clearer focus. I bet it would all be easier to test

    I still wonder how to detect when one or several actions should be executed
    Possibly the best way to set it up is to have one handler for each possible page which might be generated in response to a particular request type. Only one would ever be active.

    Individual handlers might break down into queues of actions if there are several things to do. They might need to be atomic. There could be further chains of responsibility - whatever. The simplest of examples could just be:

    PHP Code:
         class HttpStatus404 // implements Handler
         
    {
             
    /*
                 return (true) - always active if called
             */
             
    function try()
             {
                 
    header("HTTP/1.0 404 Not Found");
                 include(
    '404.htm');
                 return 
    true;
             }
         } 
    This is used with a chain controller class which runs through a list of handlers calling the try() method until it finds one which returns true. A 404 handler would often be stuck on the end of a chain to sweep up.

    A CoR *is* just a switch-case, but with classes.

  7. #57
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Overrunner: Maybe go the CommandDictionary way? Like calculating the Composite Commands/Actions before, pass the dictionary to the FC and it executes and action in the Dictionary based on input. The Dictionary will know about subcommands/subactions and can execute them all then.

  8. #58
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I'd see that as a good thing: one class trying to do lots of different things gets refactored into smaller, more focussed classes. All that's left behind is some control logic - which also comes into clearer focus. I bet it would all be easier to test
    Quote Originally Posted by McGruff
    Possibly the best way to set it up is to have one handler for each possible page which might be generated in response to a particular request type. Only one would ever be active.
    Yep, I'm sure it will be easier to test but I think it will also be harder to maintain! It is one class per possible page (by a possible page, I mean the combination of action(s) which will be executed).
    How about creating an XML-file for each possible page instead (or perhaps one large XML). Each XML-file should hold the names of the action(s) which is mapped to a request. E.g, the request http://www.example.com/index.php?sec...&action=latest will be mapped to, say 3 actions. The ApplicationController would have to load the right XML-file, put the actions in a chain and execute it.
    XML-files are easier to maintain, no?

  9. #59
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey, people, we're talking PHP here. It keeps me amazed that everyone keeps trying to introduce into PHP what it already has.

    Web framework? PHP is a freaking Web framework! XML setup files? Ini files (http://www.php.net/parse_ini_file) is even easier to maintain. Mapping actions? That's what Web server is for. And so on.

    Other languages, like Java, Python etc. need those things because they weren't designed with ease of Web development in mind. PHP was, and we should use its strengths instead of trying to fit the square peg into a round hole.

  10. #60
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You still need to map requests to actions, even in php. A single request might be served by a whole range of possible pages. Just off the top of my head: bad request syntax? A 400 page. Not authenticated? A login page. Not authorised? A 403 page. Missing values in a form submission? Redisplay the form. And so on.

  11. #61
    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 McGruff
    You still need to map requests to actions, even in php. A single request might be served by a whole range of possible pages. Just off the top of my head: bad request syntax? A 400 page. Not authenticated? A login page. Not authorised? A 403 page. Missing values in a form submission? Redisplay the form. And so on.
    That's what header('Location ...') is for.

  12. #62
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Web framework? PHP is a freaking Web framework! XML setup files? Ini files (http://www.php.net/parse_ini_file) is even easier to maintain. Mapping actions? That's what Web server is for. And so on.
    Well, in that case php is a procedural and fairly low-level framework. The idea of building on top of it is to provide abstractions witch makes it easier to maintain larger applications than your average HelloWorld.
    As long as you aren't using the features of an objectoriented construct, you may rightfully argue that it's overhead.

  13. #63
    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 BerislavLopac
    That's what header('Location ...') is for.
    You would still need to make a decision on whether to redirect based on the request state, or some other state.

  14. #64
    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 McGruff
    You would still need to make a decision on whether to redirect based on the request state, or some other state.
    So where is a problem? The regular request is handled by request state; if, during execution, the application encounters a state that is not desired, it can easily redirect to another Page Controller.

  15. #65
    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 BerislavLopac
    So where is a problem? The regular request is handled by request state; if, during execution, the application encounters a state that is not desired, it can easily redirect to another Page Controller.
    And therein lies the heart of the issue. For simple application, staight forward procedural PHP scripts work best.

    But why to so many people search for something more? I think it is becuase as complexity rises in an application, the spagetti code nature of this approach becomes more appearant as you play a game of "hunt for the relevant script".

    The opposite approach is to choose to have a pattern/OOP based approach, where you can establish a known set of relationships between objects (perhaps MVC) and then small classes become the "glue" in your application. The ramp-up time in getting familiar with this kind of style still feels like "follow the bouncing ball" looking at all the objects, but once you are over the hurdle, you can have a well tested set of small classes to maintain which will ease your maintenance headaches in the long run.

    As with all things, TIMTOWTDI and YMMV
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  16. #66
    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 BerislavLopac
    if, during execution, the application encounters a state that is not desired, it can easily redirect to another Page Controller
    The webserver knows what to do with requests for static web pages but it doesn't really know how to handle requests for dynamic pages. It will happily try to run your script with hacked and potentially dangerous input vars or if required resources such as a db server are unavailable. It doesn't have a clue what to do if a form processor can't process a form submission and it can't manage wizard-style forms. There has to be some application controller logic in the php because most of the time a single http request will map to a series of possible responses.

    Spreading this logic around by redirecting to different controllers doesn't sound like a good idea. In fact, this would just be another implementation of ChainOfResponsibility except that the logic isn't consolidated in a single location and so is less clear. It has it's uses though if you don't want a refresh to repeat the last request.

    I'm not sure: are we talking at cross purposes? I might have picked you up wrong.

  17. #67
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    TIMTOWTDI and YMMV
    What does that stand for?

  18. #68
    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 sweatje
    And therein lies the heart of the issue. For simple application, staight forward procedural PHP scripts work best.
    But I'm not talking about "straightforward procedural PHP" -- this is an OOP approach I have in mind. It's just a different look on what is considered an object.

    Consider the following code, in a file called, say, 'desired_page.php':

    PHP Code:
    <?php

    require_once('classloader.php');

    $model = new DesiredModelClass();
    extract($model->toArray());
    require(
    'templates/desired_page_template.php');

    ?>
    Here, desired_page.php is a PageController, desired_page_template.php is a View (to make the point clearer we could put the extract() call at the top of it, or even sprinkle the View throughout with the $model->getValue() calls, but this would be overdoing it), and the DesiredModel class is, well, the Model. You can't completely avoid the procedural code even in Java (which needs a main() method), and especially in PHP.

    Quote Originally Posted by sweatje
    But why to so many people search for something more?
    In my opinion, because of the contamination with Java, which is a fine language, but too widely oriented.

    Quote Originally Posted by sweatje
    The opposite approach is to choose to have a pattern/OOP based approach,
    As I (hopefully) illustrated above, this is exactly what my approach proposes.

    Believe me, I know ins and outs of Web MVC approach -- I have designed my own framework I have been using for 99% of my development, and have tried most of the ones existing on the market. The problem with most PHP MVC frameworks -- including mine -- is that they have started with a Java-like -- mostly Struts-like -- approach instead of starting with the strong points of PHP and working towards objects from there.

    Using the procedural code like above is not bad OOP -- there is no OOP police which will bring you to jail if you don't start your scripts with a new Object() call. You can't avoid procedural code even in the most oriented PHP apps, or at least you shouldn't -- the classic use of XML files for configuration is a typical for Java-based concepts, as in Java XML is the best way for transferring runtime configuration; in PHP, with its dynamic includes and stuff like variable variables, you'll get a much better performance with parse_ini_file() or even a plain include.

  19. #69
    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 BerislavLopac
    Using the procedural code like above is not bad OOP -- there is no OOP police which will bring you to jail if you don't start your scripts with a new Object() call. You can't avoid procedural code even in the most oriented PHP apps, or at least you shouldn't -- the classic use of XML files for configuration is a typical for Java-based concepts, as in Java XML is the best way for transferring runtime configuration; in PHP, with its dynamic includes and stuff like variable variables, you'll get a much better performance with parse_ini_file() or even a plain include.
    My own approach is to avoid both XML and ini files for configuration. I would much prefer to simply change some array values, or alter some parameters to the constructor of some central objects rather than manage the info from a separate file and format somewhere.

    Long live PHP configuration in PHP

    This is largly biased by the fact that I would have to do a code migration to change the file anyway, so it does not buy me anything to have the file separated from the code.

    @DarkAngelBGE
    http://www.catb.org/~esr/jargon/html/T/TMTOWTDI.html
    http://www.catb.org/~esr/jargon/html/Y/YMMV.html

  20. #70
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  21. #71
    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 sweatje
    Long live PHP configuration in PHP
    Essentially, I agree with you here, and actually this is how I do things currently.

    However, experience in dealing with non-developers, especially designers, translators and even sysadmins has thought me to keep things as simple as possible. Ini files make it very easy for me to pass to translators and not be afraid of them messing up the code (which they invariably did with XML files or straight PHP includes).

  22. #72
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My own approach is to avoid both XML and ini files for configuration. I would much prefer to simply change some array values, or alter some parameters to the constructor of some central objects rather than manage the info from a separate file and format somewhere.
    I agree. I usually have just such an array that I can pass to a Locator or Injector so I can access configuration information through a formal interface. I can always change the PHP config file to somethings else, but rarely do because as Jason says it is the simplest and most flexible solution.
    Christopher


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
  •