SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 72
  1. #26
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by 33degrees:
    What exactly do you mean by 'figure out'? I'd say that a model is generally picked based, in some way, on the request, which makes it the controller's domain.
    I think on a loose coupling between the view and the model.
    Details here

  2. #27
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Skimmed some posts, as I'm not really up-to-snuff on all the latest Pattern Terminology.

    It took a while for me to get everything working seemlessly, but thus far it works well and haven't encountered any unsurmountable snags.

    Here's an overview of what I do, and it works. Not sure if it falls into any given setup as described above.

    1. Front Controller (index.php) receives all requests.
    2. Front Controller performs pre-filters.
    3. Front Controller chooses and creates Application Controller based on request.
    4. Application Controller runs pre-filters.
    5. Application Controller chooses and created a Data Source.
    6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
    7. Model returns XML to Application Controller.
    8. Application Controller chooses and creates View, based on request, and passes XML to it.
    9. View loads necessary XSL files, performs XSLT and outputs results.
    10. Application Controller runs post-filters and tidies up.
    11. Front Controller runs post filters and tidies up.

  3. #28
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    You see, telling a model to fetch data isn't..
    I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..

  4. #29
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wish we could agree on when to use "fetch." It is commonly used to mean "get data from a database" as opposed to "load" with usually implies "get (all) data from a file" or "read" which implies a stream, whether a file, device or port. Which is pretty confusing and I imagine worse for those for which English is not their first language.

    Think of how those words apply to a book, for example. To fetch a book means to go get it and bring it back. To load a book means to put it into something. To read a book means to scan the text inside it.

    Maybe "access" or "get" for variables?
    Christopher

  5. #30
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very interesting discussion, keep it flowing
    Quote Originally Posted by kyberfabrikken
    As for the FC, I have a ChainOfResposibility with one or more RequestMappers. Each RequestMapper may have different strategies for selecting a proper Controller, or it may fall thru to the next in the chain, if it doesn't find a match.
    Why do you need more than one RequestMapper? What's the difference between your RequestMapper_ActionRequestMapper and your RequestMapper_ServerPageRequestMapper?
    Quote Originally Posted by DarkAngelBGE
    The Request is passed to the FC...the $_GET['command'] variable is matched to the CmdDictionary. If there is a command for it, execute it (or if it is a Composite Command, execute all childs as well), else execute a default Command.
    So if you want to execute several actions you load one big action (lets call it main) which executes all the actions? This approach seems very inflexible to me since it will result in an explosion of classes, no? What if I mix and match my actions, then I'd have to create a new action for every combination of actions I want to execute seqentially.
    Quote Originally Posted by DarkAngelBGE
    -Each Command holds a controller, which is executed when the command is executed. Based on the Request, the Controller loads a View and populates it with a model, which belongs to the controller.
    So your command is basically an application / page(?) controller?

    Also, I wonder why you need the CommandDictionary (storing commands?). Wouldn't it be much more simple to just fetch the Command from the filesystem. For instance like this:
    PHP Code:
    function getCommand ($commandName)
    {
      
    $file '/commands/' $commandName 'Command.class.php';
      require_once(
    $file);
      
    $class $commandName 'Command';


  6. #31
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Overrunner: About the several Actions. Why would this be inflexible? You just create an Action object and pass it to an existing Action object, like
    PHP Code:
    $action1->addChildAction($action2); 
    However, I agree that my way of doing this is still not very flexible. Open to ideas here.

    Yes, my command is as of now more or less only a controller, since it does not do much more than holding a controller. Might need it for more stuff later though.

    CommandDic is simply my way of having an ActionMap which I can populate in different ways depending on whether I deal with the AdminPanel or not. It really is only for programming closer to the problem as of now.

  7. #32
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm getting a bit behind in this topic but...

    Quote Originally Posted by DarkAngelBGE
    But then again if you have a PDFView and a HtmlView of some text that is stored in the database, both Views would include the same code for telling the model to fetch the data. Isn't that Code Repition?
    Actually it's just the reverse. The same data-collection code is re-usable with any kind of template.

  8. #33
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Overrunner: Actuallly I have refactored it all now. I just pass a Collection of Controller identifiers and the request to the fc, which tries to map the request to the list, loads a controller file dynamically and executes the controller. Thanks for your notification, I was coding blindfolded.

    So for now I got rid of CommandDictionary and Command. At my house a Controller is an Action. Weird, but ok yes?

  9. #34
    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 kyberfabrikken
    If you use DispatherView, the View pulls from the Model, whereas in the TemplateView the Model is pushed to the View (~Template) by the Controller (~Action). You may then argue that the DispatcherView isn't "true" MVC, since Controller and View are intertwined. This can be dealt with by introducing the ViewHelper witch is an object that pulls data from the Model. This gives you back your VC seperation, since the controller-logic is now in the ViewHelper.
    So in the DispatcherView you have the Controller represented by the ViewHelper, while in the TemplateView you have the Controller represented by the Action.
    I think it's maybe easier to understand if you think of "control" as making decisions - including which view to display. Other entities actually do all the work. The controller can ask a view to update itself but it can't get involved in the details of that task (at least not in MVC). Objects which help create a view are part of the view layer not the controller layer. Controllers will manipulate the model, views will read from the model and never the twain shall meet.

  10. #35
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think McGruff's explaination is an excellent one. Controllers probably got their name from association with electro-mechanical controllers. Those controllers tell a device to do something (e.g. a valve to open/close) but are neither the device itself (i.e. the valve), nor the mechanism the controller talks to (i.e. motor and gearbox).
    Christopher

  11. #36
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..
    Right, what I meant is that the model needs to fetch data from the database, and it's the controller's job to the tell the model what data to fetch, based on the request.
    Here's an overview of what I do, and it works. Not sure if it falls into any given setup as described above.

    Quote Originally Posted by Viflux
    1. Front Controller (index.php) receives all requests.
    2. Front Controller performs pre-filters.
    3. Front Controller chooses and creates Application Controller based on request.
    4. Application Controller runs pre-filters.
    5. Application Controller chooses and created a Data Source.
    6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
    7. Model returns XML to Application Controller.
    8. Application Controller chooses and creates View, based on request, and passes XML to it.
    9. View loads necessary XSL files, performs XSLT and outputs results.
    10. Application Controller runs post-filters and tidies up.
    11. Front Controller runs post filters and tidies up.
    Interesting; in regards to steps 5 and 6, I'm curious to know how this works exactly; by Data Source do you mean a specific server and database name? Or can your models get data from a variety of sources (i.e. Databases, text files, etc)

    Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...

  12. #37
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    Degrees, did you look at the code samples I posted above? What do you think of them?
    Yes, here's what I would do:

    In the controller

    PHP Code:
    <?php
    /**
    * Author: Tim Koschützki
    * Date Started: April 7th, 2005
    */
    require_once('IssueController.php');

    class 
    DeleteIssueController extends IssueController {
        public function 
    DeleteIssueController (&$dao,$input=null) {
            
    parent::__construct($dao$input);
        }
        public function 
    execute() {    
            if(!isset(
    $this->input['submit'])) {
                require_once(
    ISSUE_VIEW_PATH.'DeleteIssueItemView.php');
                
    $this->model->listIssue($this->input['id']);
                
    $this->setView(new DeleteIssueItemView($this->model$this->lang));
            } else {
                
    $success=0;
                if(
    $this->model->deleteIssue($this->input['id'])) {
                    
    $success=1;
                }
                
                require_once(
    ISSUE_VIEW_PATH.'IssueItemHasBeenDeletedView.php');
                
    $this->setView(new IssueItemHasBeenDeletedView($this->model$this->lang$success));
            }
        }
    }

    ?>
    And for the view

    PHP Code:
    <?php
    /**
    * Author: Tim Koschützki
    * Date Started: April 7th, 2005
    */
    require_once(LIB_PATH.'Template.php');
    require_once(
    'IssueView.php');

    class 
    DeleteIssueView extends IssueView {

        
    //! A constructor.
        /**
        * Constucts a new IssueItemView object
        * @param $model an instance of the IssueModel class
        */
        
    public function __construct(&$model,&$lang) {
            
    parent::__construct(&$model,&$lang);

        }

        
    //! A manipulator
        /**
        * Renders a single issue
        * @return void
        */
        
    private function deleteIssueItem() {   
            
    $tmp =& new Template('delete_issue_confirm');        
            
    $tmp->setValue('{ISSUE_ID}',$this->model->ID);
            
    $tmp->setValue('{ISSUE_TITLE}' => $issue['title']);
            
            
    $tmp->parse();
            return 
    $issueTemplate->fetch();
        }

        public function 
    display () {
            
    $tmp =& new Template('standard');    
            
    $tmp->setValue('{HEADER}',$this->header());
            
    $tmp->setValue('{FOOTER}',$this->footer());
            
    $tmp->setValue('{NAVBAR}',$this->navbar());
            
    $tmp->setValue('{CONTENT}',$this->deleteIssueItem());
            
    $tmp->parse();
            return 
    $tmp->fetch();
        }
    }

    ?>
    The model->listIssue() command is now in the controller, which is where I feel it belongs, and which is incidentally where you had placed the model->deleteIssue(); both commands manipulate the model in some way, and that's why they belong the controller.

    Also, since the model already contains the data the ID of the item to be deleted, there's no longer any need for the controller to pass it seperately and for the view to store it.

    Other than that, it looks good to me!

  13. #38
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Allow me to recap on TemplateView vs. DispatcherView...
    Thanks, I had been a bit confused regarding the difference between the two; now I know that my prefered approach is using a DispatcherView.

    Quote Originally Posted by atu
    I think on a loose coupling between the view and the model.
    Details here
    Looking at that diagram, the view is inside the controller, and is doing things like appending filters and authentication; I would argue that those things aren't presentation logic, and that this view is really just a controller, with the template being rendered a TemplateView.

  14. #39
    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
    Looking at that diagram, the view is inside the controller, and is doing things like appending filters and authentication
    This (SMART) may or may not be a good design but it's certainly not MVC. Here's the WACT wiki entry on MVC: http://wact.sourceforge.net/index.ph...ViewController




    1. Front Controller (index.php) receives all requests.
    2. Front Controller performs pre-filters.
    3. Front Controller chooses and creates Application Controller based on request.
    4. Application Controller runs pre-filters.
    5. Application Controller chooses and created a Data Source.
    6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
    7. Model returns XML to Application Controller.
    8. Application Controller chooses and creates View, based on request, and passes XML to it.
    9. View loads necessary XSL files, performs XSLT and outputs results.
    10. Application Controller runs post-filters and tidies up.
    11. Front Controller runs post filters and tidies up.
    OR:


    Front Controller (index.php) receives all requests.
    Front Controller performs pre-filters.
    Front Controller chooses and creates Application Controller based on request.

    Application Controller selects a view and tells it to update itself
    Front Controller runs post filters and tidies up.
    Last edited by McGruff; May 18, 2005 at 22:21.

  15. #40
    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 Captain Proton
    I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..
    Just to expand a bit, the model performs domain logic on raw data obtained from persistent storage, amongst other things. Data obtained from the domain layer has some kind of added value compared to data obtained direct from the data access layer.

  16. #41
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Degrees for your code sample. What do the others think of what Degrees posted?

  17. #42
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hrm actually I dunno. I think this is not really important whether the controller tells the model to select an issue or the view tells the model to select the issue. This code does not manipulate the model in any way, the model is still independant of the presentation. I agree though that everything that manipulates the model should be in the controller. That's what Fowler's been saying as well.

  18. #43
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by McGruff
    This (SMART) may or may not be a good design but it's certainly not MVC.
    Thats correct.

    IMO following 100% the mvc definition results in overcomplicated design.

  19. #44
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by atu
    IMO following 100% the mvc definition results in overcomplicated design.
    Which one do you regard as the MVC definition?

  20. #45
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by DarkAngelBGE
    Which one do you regard as the MVC definition?
    Thats a good question. May the reason for some confusions is here.

  21. #46
    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 overrunner
    Why do you need more than one RequestMapper? What's the difference between your RequestMapper_ActionRequestMapper and your RequestMapper_ServerPageRequestMapper?
    They follow different rules for determining the target. The ActionRequestMapper would recognize a $_GET['action'] and create an Action object. The ServerPageRequestMapper would match a regex against $_SERVER['REQUEST_URI'], and return a DipatcherView object with the filename. You could make up new rules ... for instance you might crete a CommandDictionaryMapper, witch holds degree's CommandDictionary.
    It allows me to combine different strategies for mapping the request ... actualy it makes it possible to use TemplateView for some pages and DispatcherView for others.

    Quote Originally Posted by 33degrees
    now I know that my prefered approach is using a 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.

    Quote Originally Posted by 33degrees
    Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...
    Regarding XML/XSLT for Views, I think there is a great potential for using DipatcherView. With XML_Transformer you could use callbacks to ViewHelpers from within te XML-document (the View). I have been toyed with this, but haven't actualy used it.
    This way you won't have big xml-documents in memory, since the ViewHelper will just fetch what is needed.

  22. #47
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    for instance you might crete a CommandDictionaryMapper, witch holds degree's CommandDictionary.
    It is "my" CommandDictionary.

    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?

  23. #48
    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 DarkAngelBGE
    It is "my" CommandDictionary.
    Sorry - I just skimmed back thru the thread, and saw 33degrees post some code.

    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?
    Well - for one thing, it's easier to narrow it down to just what you need, with the pull-method, than with the push. Also - If the View really need nothing from the Model, it's overhead to have a push-architecture.

    Quote Originally Posted by DarkAngelBGE
    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?
    You may have a point here - I'll have to consult the holy text on that. Whether or not Fowler says it, I'd argue that the seperation is healthy nevertheless.

  24. #49
    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 33degrees
    Interesting; in regards to steps 5 and 6, I'm curious to know how this works exactly; by Data Source do you mean a specific server and database name? Or can your models get data from a variety of sources (i.e. Databases, text files, etc)

    Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...
    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.

  25. #50
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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?

    Well - for one thing, it's easier to narrow it down to just what you need, with the pull-method, than with the push. Also - If the View really need nothing from the Model, it's overhead to have a push-architecture.
    Don't quite understand. Whether the controller fetches the data and sends an updated model to the view or the view tells the old model to fetch some data both stands for a pull method. The View pulls the data from the View. It's just whether the controller tells the model to update itself or the View.

    Maybe I did not understand what you meant though.


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
  •