SitePoint Sponsor

User Tag List

Page 11 of 16 FirstFirst ... 789101112131415 ... LastLast
Results 251 to 275 of 384
  1. #251
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    "dispatching model"? can you explain that, I don't understand what you mean by it.
    My mistake. It should have been load or lazy load the model (and view).

    Quote Originally Posted by Captain Proton
    I really don't understand the things in this thread anymore, actions, handles, flow controllers, dispatching, locator?? It seems like you are making a design that allows for 30 variations of the same 'thing' in different places.

    Guess that's what happens when you try to build things on vaguely defined concepts (which is what MVC is, hehe, or at least I think precisely because it is so vaguely defined ).
    I think one of the positive goals of these "skeleton" threads is that we are trying build code that supports many ways to do things rather than build just another framework. I would hope that eventually we will have one or two codebases that have flexible code so that two programmers can build slightly different frameworks using the same codebase (or the same programmer building different frameworks for different projects from the same codebase). I think that is much more powerful than using one framework for large projects and totally separate code for small projects.
    Christopher

  2. #252
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    In an effort to clarify what I was rambling about in my last post, this is what I mean by the two approaches :
    OK, but how does the following line (which does in essence what I have been talking about) work?
    PHP Code:
            $gateway =& $context->getGateway('Foo'); 
    And why call it Gateway rather than Model (which could be a DataSpace, ORMapper, Gateway, Domain Model, etc.)? And why put it in the Context when you would want it Lazy Loaded by the Action?

    And if most Actions have a Model then why not just have:
    PHP Code:
            $model =& $this->getModel('Foo'); 
    Christopher

  3. #253
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    (...)
    I think those things are implementation-specific and non-essential. You seem to be picking on the examples' details a lot lately.

    So as to contribute something once in a while, I've written an ActionPackMapper that can be used with INI files. There's an additional IResource interface for reading/writing data (eg. from a file) and an IniReader that implements it. A FileResource is used to persist the created routes so as to avoid parsing them every time a new request comes in.

    The INI input looks like this:
    Code:
    [archives/:year/:month/:day]
    
    	controller			= "Archives"
    	action				= "view"
    	
    	match.year			= "[0-9]{4}"
    	match.month			= "[0-9]{2}"
    	match.day			= "[0-9]{2}"
    	
    	optional			= "day"
    
    [:controller/:action/:id]
    
    	controller			= "Default"
    	action				= "default"
    
    	match.id			= "[0-9]+"
    	
    	optional			= "id"
    I think that's pretty self-descriptive. Interested in seeing the whole lot of it?

    Oh, and there are some tests, too!
    Last edited by Ezku; Aug 4, 2005 at 13:01.

  4. #254
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interested in seeing the whole lot of it?
    Bring it on...

  5. #255
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, here's a release then. Managed to shave off a few bugs while I was at it.

    Some features, like the EventHandler+Delegate combo, aren't included. (I used them to automate Session committing by having the Response host an EventHandler that has an onResponse event.) I can update this to include them if you want to, though.
    Attached Files Attached Files

  6. #256
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    I think those things are implementation-specific and non-essential. You seem to be picking on the examples' details a lot lately.
    I'm not sure which examples you thought were implementation-specific so I can't comment. I agree that I am focusing on the details because once you get past the general design of the controllers things get detailed and complex. It is pretty easy to build a framework that just works one way (there are thousands of them), but it is difficult to build code that can be used many different ways.
    Christopher

  7. #257
    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 arborint
    It is pretty easy to build a framework that just works one way (there are thousands of them), but it is difficult to build code that can be used many different ways.
    If you over weigh it to the point that the only people who can use it are those who developed it, you won't need to worry too much about the code being used in many different ways.

    Douglas
    Hello World

  8. #258
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    If you over weigh it to the point that the only people who can use it are those who developed it, you won't need to worry too much about the code being used in many different ways.
    True, but so far I think it has been kept fairly clean with basic classes that can be combined in various ways. The thing that will make is usable are example programs that show the various combinations and can be used as a starting place.

    The Front Controller started this process. It is a very simple dispatcher that can accept differnet mappers to have different behaviors. The Front Controller can be optionally wrapped in a filter chain. That's a pretty flexible system that can do everything from just loading PHP pages, to Struts style, to Rails style ActionPack.

    The other controllers are still cooking, but I think the process of thinking through the various Page, Input, Application, Form, etc. controllers was beneficial. The state machines went two directions (success/failure FlowController and state/transition AppController) which I think has added options to the mix.

    The current experimentation hiatus (from my point of view) is working through the issues of Request/Response vs Context vs Locator, and dealing with the intracacies of getting the various controller classes to work together in a coherent way.

    These are complex and sometimes suble problems. They require adding support code here and there to get the necessary functionality which causes incompatibities. And when you get into these controllers that are in contact with the actual application code, the number of supporting classes needed grows. I note from looking at Ezku's code that it has become fairly different from mine, and there are a number of new classes, but the common interfaces are pretty much the same. I know kyberfabrikken has his own framework into which he has rolled some of these ideas, so I don't think he is working on any of this code currently.

    My goal is to maintain the ability to dispatch everything from a Plain Old PHP pages to Transaction Script classes to MVC with three separate class files and any kind of template. I currently have two small sites I need to do and I was thinking of using them to see if I could get my current "skeleton" code from where it is now to actual production code. For me, that means Input Controller for pages, Pager Controller for lists, Form Controller, and Application Controller for multi-page/form wizards. Kyberfabrikken and Ezku's work using a Context object have me thinking about abandoning passing around Request/Response objects for a generic Locator I mentioned above.

    Doug, I know you have mentioned several times that the names and discussion are difficult to follow for those who are not familiar with the code (which is probably very true). I'd be interested to know what you'd like to see as far as examples so that you could understand the various "skeleton" code.
    Christopher

  9. #259
    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 arborint
    OK, but how does the following line work ?
    Basically I don't care. Probably it returns a TableDataGateway, but really that would depend on which type of model-layer the programmer would use.

    Quote Originally Posted by arborint
    And why put it in the Context when you would want it Lazy Loaded by the Action?
    I probably added some distraction by fetching the gateway from a servicelocator (context) rather than instantiating. In hindsight that was needless - I could have just typed :
    PHP Code:
    $gateway =& new FooGateway(); 
    Quote Originally Posted by arborint
    And why call it Gateway rather than Model
    That's on pupose.
    For me, the Model is an abstract body of several classes, spanning from database-connection, while the concrete gateway in this case is a tabledatagateway. (and the object returned might be an activerecord)

    Quote Originally Posted by arborint
    I know kyberfabrikken has his own framework into which he has rolled some of these ideas, so I don't think he is working on any of this code currently.
    I have tried to keep quiet about this on purpose. konstrukt is mainly the result of some collaboration between myself and one of my colleagues at work. It's still rather sketchy as a whole, so I have kept it rather anonymous at sf. We're nearing something that actually works though, and theese threads have been a great input. You're welcome to take a peek at the cvs.

  10. #260
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Basically I don't care. Probably it returns a TableDataGateway, but really that would depend on which type of model-layer the programmer would use.

    I probably added some distraction by fetching the gateway from a servicelocator (context) rather than instantiating. In hindsight that was needless - I could have just typed :
    PHP Code:
    $gateway =& new FooGateway(); 
    OK. What you are saying is that the Action (which is really the controller) should manually instansiate the Model and View and connect them together as needed. The "skeleton" support currently supports only custom coded actions. What I was looking for was some automation of this because maybe 20% of the time I have a complex combination of Models and Views, but 80% of the time it can be just:
    PHP Code:
    include 'view/MyView.php';
    include 
    'model/MyModel.php';
    $view =& new MyView(new MyModel($DBConnection));
    return 
    $view->render('templates/MyTemplate.php'); 
    which could be all reduced to something like:
    PHP Code:
    $mvc = new MVCHandler('My'$DBConnection);
    return 
    mvc->execute(); 
    which would remove a lot of repetetive code from applications while at the same time organizing the files in a structured manner.
    Quote Originally Posted by kyberfabrikken
    That's on pupose.
    For me, the Model is an abstract body of several classes, spanning from database-connection, while the concrete gateway in this case is a tabledatagateway. (and the object returned might be an activerecord)
    I think my question was, how does the global Context know what Gateway this action needs? It looks like there would be only one Gateway per application allowed.
    Christopher

  11. #261
    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 arborint
    OK. What you are saying is that the Action (which is really the controller) should manually instansiate the Model and View and connect them together as needed. The "skeleton" support currently supports only custom coded actions. What I was looking for was some automation of this (...)
    Ah - I see. I suppose we could make some default actions and map to them in the same way as we do with ServerPage's. Eg.:
    PHP Code:
    $action =& new DefaultAction($request->get('action')); 
    Another approach is to simple let the action inherit from a default action. I like that better, since you don't have to change the mapping when/if you expand it later. The only problem with this is that you need to create a file per action, even if it just contains :
    PHP Code:
    class MyAction extends DefaultAction
    {
        var 
    $modelname "foo";

    Quote Originally Posted by arborint
    I think my question was, how does the global Context know what Gateway this action needs? It looks like there would be only one Gateway per application allowed.
    hm ... I passed a parameter to the function - that would identify the table. So one gateway per table per application, but isn't that what you'd want ?

  12. #262
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Ah - I see. I suppose we could make some default actions and map to them in the same way as we do with ServerPage's. Eg.:
    PHP Code:
    $action =& new DefaultAction($request->get('action')); 
    I have not been explaining this very well. Yes but I think DefaultMVCAction is what I am looking for you so you don't have to code a custom action if you want to do it in a structured way.
    Quote Originally Posted by kyberfabrikken
    Another approach is to simple let the action inherit from a default action. I like that better, since you don't have to change the mapping when/if you expand it later. The only problem with this is that you need to create a file per action, even if it just contains :
    PHP Code:
    class MyAction extends DefaultAction
    {
        var 
    $modelname "foo";

    You should probably be able to do it either way. But have a small action for each might be a good thing as it documents things and is the same as building a custom action.
    Quote Originally Posted by kyberfabrikken
    hm ... I passed a parameter to the function - that would identify the table. So one gateway per table per application, but isn't that what you'd want ?
    I usually have some common Gateways (e.g. UserGateway, ProductGateway, etc.) that I use several places and then have some action specific Gateway classes. But they don't always have the same interfaces because sometimes there are additional findBy...() methods needed.
    Christopher

  13. #263
    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 arborint
    You should probably be able to do it either way. But have a small action for each might be a good thing as it documents things and is the same as building a custom action.
    Agreed.
    Quote Originally Posted by arborint
    I usually have some common Gateways (..) and then have some action specific Gateway classes.
    They'll have different names though - so to get a specific gateway, we could do :
    PHP Code:
    (...)
    $gateway =& new SpecificFooGateway();
    (...) 
    Or
    PHP Code:
    <?php $foo =& $this->get('specificfoo/getbypk/1'); ?>
    <p>
        zik : <?=$foo->getZik()?>
        <br />
        zok : <?=$foo->getZok()?>
    </p>
    Btw. If things are getting really ugly, there's no reason why you couldn't instantiate an action within a serverpage, and use it for rendering part of the view. (such as a widget)

  14. #264
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Agreed.

    They'll have different names though - so to get a specific gateway, we could do :

    Btw. If things are getting really ugly, there's no reason why you couldn't instantiate an action within a serverpage, and use it for rendering part of the view. (such as a widget)
    I think what I am really looking for is a standard Action/Controller that maps Actions, Models and Views together, Use the following three files as an example:

    action/NewUserAction.php
    view/NewUserView.php
    model/UserGateway.php

    But how do you turn, for example, "index.php?action=NewUser", into this in a clean way. In this case the Action and View names can be derived, but we would need to lookup the model name which implies that we need some kind of configuration information. Perhaps we could just do it in a MVC Controller like:
    PHP Code:
    class NewUserAction extends ControllerMVC {
        function 
    execute($request$response) {
            
    $this->setModelClass('UserGateway');
            
    $this->setViewClass('NewUser');
            
    parent::execute($request$response);
        }

    I know we could just do this manually with just a few more lines, but this would enforce separate files to keep the actions from becoming Transaction Scripts. What do you think?
    Christopher

  15. #265
    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 arborint
    I think what I am really looking for is a standard Action/Controller that maps Actions, Models and Views together, Use the following three files as an example:

    action/NewUserAction.php
    view/NewUserView.php
    model/UserGateway.php
    You are implying that there is a 1:1 relationship between action and model. But you could well have multiple actions using the same gateway. You could also have one action utilizing several gateways. Or none.

  16. #266
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I have tried to keep quiet about this on purpose. konstrukt is mainly the result of some collaboration between myself and one of my colleagues at work. It's still rather sketchy as a whole, so I have kept it rather anonymous at sf. We're nearing something that actually works though, and theese threads have been a great input. You're welcome to take a peek at the cvs.
    You might want to make your database model of the konstruct cms as seen in the CVS a bit differently.In my opinion it's more flexible when you can define properties and objects so that you won't need a seperate table for each node type instead.

  17. #267
    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 wdeboer
    You might want to make your database model of the konstruct cms as seen in the CVS a bit differently.In my opinion it's more flexible when you can define properties and objects so that you won't need a seperate table for each node type instead.
    I take it that you're suggesting to make a repository of classless objects ?
    The overall strategy is that objects (ActiveRecords) are representations of database-structures, rather than one where the database is reduced to a storage for objects.

    Therefore, I prefer a strong typing where classes maps to tables, over one where the objects properties are in sperate tables.
    You'll also observe that I don't map relationships. The user has to be aware of theese himself.

  18. #268
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    You are implying that there is a 1:1 relationship between action and model. But you could well have multiple actions using the same gateway. You could also have one action utilizing several gateways. Or none.
    Actually no. I was trying to point out in my example that Models (and therefore Views) could be reused by different actions. I said, "In this case the Action and View names can be derived, but we would need to lookup the model name..." to show that while NewUserAction and NewUserView might be used only once, the class UserGateway would be used by many actions. That is probably the most commons situation and the one I am trying to get some code reduction for.

    It is easy to map if the MVC classes are named NewUserAction, NewUserModel, NewUserView. But they are more often named something like: NewUserAction, UserGateway, UserProfileView, so the names needs to be supplied via a map or directly in the code
    Christopher

  19. #269
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Stillwater, MN
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe I'm missing something but what's wrong with this:
    PHP Code:
    class NewUserAction extends ControllerMVC {
        function 
    execute($request$response) {
            
    $name_taken UserGateway::find($request->get('username'));
            if (!
    $name_taken) {
                
    $user UserGateway::create(...);
                
    $this->setView('newUserSuccess');
            } else {
                
    $this->setView('userNameTaken');
            }
        }

    I don't see a need to map the model, as one controller can use many models. Perhaps my mind is corrupted by Rails?
    Last edited by Radley; Aug 7, 2005 at 20:08. Reason: Syntax error

  20. #270
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Radley
    Maybe I'm missing something but what's wrong with this:

    I don't see a need to map the model, as one controller can use many models. Perhaps my mind is corrupted by Rails?
    Nothing wrong that that at all. This is in context to the 'skeleton' code in this thread. We can currently dispatch essentially "empty" Actions where you supply all the code to create the Model and View and connect them. I have been inquiring about how to simplify the code for the most common MVC actions to the point where maybe you don't need to code an Action at all in those cases.

    I notice in your example that the controller contains a specific call to set the View but that you don't show how the Model gets to the view. What would the setView() function look like?
    Christopher

  21. #271
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Stillwater, MN
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I notice in your example that the controller contains a specific call to set the View but that you don't show how the Model gets to the view. What would the setView() function look like?
    I kind of forgot about that. Instead I believe it would be like this:
    PHP Code:
    class NewUserAction extends ControllerMVC {
        function 
    execute() {
            
    $name_taken UserGateway::find($this->request->get('username'));
            if (!
    $name_taken) {
                
    $user UserGateway::create(...);
                
    $this->view->setParam('user'$user);
            } else {
                
    $this->setView('userNameTaken');
            }
        }

    I changed a few things to get it to work.

    -- I moved the inputting of Request and Response to a separate method in the parent class to reduce duplication. I also defined an output method which is called in the front controller that sets the response to the output of the view.
    PHP Code:
    function execute(&$request, &$response) {
        
    $handler =& $this->mapper->mapRequest($request);
        if (
    method_exists($handler'execute')) { // instanceOf IHandler
            
    $handler->setEnv($request$response);
            
    $handler->execute();
            
    $handler->output();
        }

    -- I added 2 new methods to the ControllerMVC class:
    PHP Code:
    function setMapper(&$mapper) {
        
    $this->mapper $mapper;
    }

    function 
    setView($name) {
        
    $this->view $this->mapper->mapView($name);

    -- I also added a mapView method to the mapper that maps a simple name to a view (basic class or template object) depending on which mapper you used.
    -- I changed the last few lines of mapRequest to map the view also (ActionMapper is shown):
    PHP Code:
    $action = new $classname;
    $action->setMapper($this);
    $action->setView($classname);
    return 
    $action
    This sets a default view and passes the mapper to the controller.

    With this setup (using the Action Mapper), "index.php?action=NewUser" would be mapped to NewUserAction, NewUserActionView. No mapping is done for the model. As before this can easily be swapped for another mapper.

    Thoughts?

  22. #272
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Radley
    I kind of forgot about that. Instead I believe it would be like this:
    PHP Code:
    class NewUserAction extends ControllerMVC {
        function 
    execute() {
            
    $name_taken UserGateway::find($this->request->get('username'));
            if (!
    $name_taken) {
                
    $user UserGateway::create(...);
                
    $this->view->setParam('user'$user);
            } else {
                
    $this->setView('userNameTaken');
            }
        }

    Interesting. I think I see where you are going with this. I think it clarifies my questions a little. My main question (and probably the biggest question in MVC) is which code goes into the Controller, Action, or View. I think we should be able to easily allow code to move between the three because implementation flexiblity is one of the goals of the "skeleton" code (as opposed to a framework).

    For example, If we changed the above code so that it was the View it would look like this:
    PHP Code:
    class NewUserAction extends ControllerMVC {
        function 
    execute() {
            
    $model = new UserGateway(...);
            
    $name_taken $user->find($this->request->get('username'));
            if (! 
    $name_taken) {
                
    $model->create(...);
            }
            
    $this->view->execute($model)
        }


    class 
    NewUserView extends View {
        function 
    execute($model) {
            if (! 
    $model->error()) {
                
    $this->view->setParam('user'$model->getUsername());
            } else {
                
    $this->setView('userNameTaken');
            }
        }

    That makes the View just presentation and the Action/Controller turns into a mini-Transaction Script that contains the logic for the action. The view certainly only has presentation logic at this point. But does the Controller have business logic that should be in the Model? Or is it program logic, not business logic? Or is the price you pay for having a generic Gateway object that your Model has a little business logic leaks into the Controller?
    Christopher

  23. #273
    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)
    Basically this whole thing could be dealt with by providing some parameterized default controllers. That's more or less the same thing you are both suggesting.

    Anyway - I think this approach takes a preconception of a very tableoriented design. One tablegateway -> one crud. While it's a common design to do it this way, it's not nescesarilly the only, or the best way. Thus I think it's rather important to make such a concept optional. The implementation could follow a "ActionPack-style" controller, and we would end up with something very similar to rails. For a strictly table-centric design, this will probably work very well.

  24. #274
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Basically this whole thing could be dealt with by providing some parameterized default controllers. That's more or less the same thing you are both suggesting.
    I think you are right. I'm just not sure where the "parameters" are added.
    Quote Originally Posted by kyberfabrikken
    Anyway - I think this approach takes a preconception of a very tableoriented design. One tablegateway -> one crud. While it's a common design to do it this way, it's not nescesarilly the only, or the best way. Thus I think it's rather important to make such a concept optional.
    I agree and have tried to be careful to always say Model even though there is a Gateway in the examples. Allowing reuse of Models an important goal.
    Quote Originally Posted by kyberfabrikken
    The implementation could follow a "ActionPack-style" controller, and we would end up with something very similar to rails. For a strictly table-centric design, this will probably work very well.
    In looking at Radley's examples I think I have noticed something. If the Action needs to write data then it probably needs a custom Controller like the examples above. But Actions that write are the minority in most web applications. If all the Action needs to do is read data from a data source then all the controller needs to do (most of the time) is pass the Model to the View. Perhaps a read-only Controller that somehow accepted parameters (or a action mapper) would work:
    PHP Code:
    class ReadOnlyController {
        function 
    ReadOnlyController($modelclass$viewclass)  {
        }

        function 
    execute() {
            
    $view =& $this->getView();
            
    $view->execute($this->getModel())
        }

    Christopher

  25. #275
    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 arborint
    I think you are right. I'm just not sure where the "parameters" are added.
    It could be dealt with by simply passing a parameter on the request. This is of course less flexible, but much simpler. Eg :
    PHP Code:
    class CrudIndexAction
    {
        function 
    execute(&$context) {
            
    $gateway =& TableGateway::getGateway($context->request->get("table"));
            
    $t =& new Template("index.tpl");
            
    $t->set("list"$gateway->getList());
            
    $context->response->setContent($t->render());
        }

    In this case there will be only one CrudIndexAction for all the tablegateways, which isn't as flexible. For one thing you can't change the template for a single datatype without affecting all the other. This may or may not be a problem.

    If it is in fact a problem, the next step could be to create a concrete descendant per table. Eg. :
    PHP Code:
    class BaseIndexAction
    {
        var 
    $table NULL;
        function 
    execute(&$context) {
            
    $gateway =& TableGateway::getGateway($this->table);
            
    $t =& new Template("index.tpl");
            
    $t->set("list"$gateway->getList());
            
    $context->response->setContent($t->render());
        }
    }

    (...)

    class 
    UserIndexAction extends BaseIndexAction
    {
        var 
    $table "user";

    This is basically how rails is constructed.
    The biggest problem with this design is that you are forced to create a lot of files that may be really trivial (simply extends a baseclass). In rails it doesn't seem that scary, since actions are grouped together in namespaces (called "controllers" in rails).


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
  •