SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 106
  1. #51
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now, what I don't personnally like is the use of classes, that represent a GUI. For example LoginBox, Table, Header, Footer. These classes easily change for every project, and the need of every user. This is all for the View part.

    For example
    PHP Code:
    return $this->render('login.tpl.php'); 
    What if I want to place two or three Login boxes on one page?

    And why should the LoginBox class validate the data???

    The Controller finds, if there is data submitted, sends it to the Model for validation, and based on its answer, displays or not the loginbox from the View.

  2. #52
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    What if I want to place two or three Login boxes on one page?
    But this is not a framework, but the code for my own project. There is only one loginbox and one user who uses the code. Why should I change anything to reflect the situation you described, if I know it won't happen. Ever.
    Quote Originally Posted by REMIYA
    And why should the LoginBox class validate the data???
    I asked about it earlier, but the response was, that the validation should run in the controller, not the model...
    loginbox is actually a childcontroller and I wanted to put the validation there, so I have all the things related to this component separated from the main controller. What's wrong with that? I was following some guides here and I thought it's OK (I also liked this solution).

    So I'll ask the question too: what's wrong in validating the user data in the login component? I might agree on validation in the model (that was my first thought actually), but there were some arguments against here. SO now I'm a bit confused..

  3. #53
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dan7
    But this is not a framework, but the code for my own project. There is only one loginbox and one user who uses the code. Why should I change anything to reflect the situation you described, if I know it won't happen. Ever.
    This is the answer of the question. It its not flexible. Probably you won't use it in another project. Or if someone else uses it, he might have to change the class code, which is not desired.

    Quote Originally Posted by dan7
    So I'll ask the question too: what's wrong in validating the user data in the login component? I might agree on validation in the model (that was my first thought actually), but there were some arguments against here. SO now I'm a bit confused..
    You can have different type of Controllers. If the login is heavy, you may have a separate Login Controller.
    However in most of the cases, you won't need it. So keep the good KISS principle.
    Last edited by REMIYA; Aug 28, 2006 at 11:46.

  4. #54
    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)
    This thread has mostly been a ping-pong between dan7 and myself. There are definately no definite answer in this, so for a large part everything so far is my personal oppinion. And I think that my oppinion may be a bit different from remiya's.

    A few answers/comments :

    Quote Originally Posted by REMIYA
    1) MVC is nothing more than a concept. It is an idea. Just like OOP is a concept, and idea. A programmer can easily code without bothering with OOP and MVC. However implementing these ideas, brings the code to the next level.

    2) MVC is nothing more than separation of logic. The Controller has nothing to do with View, nor View has to do with Model. If it does, then you are doing something wrong.
    MVC is a way of layering. Like with any type of layering, each layer has an interface against eachother. The aim is to minimize and formalize this interface, but not to remove it.

    Quote Originally Posted by REMIYA
    3) MVC should closely follow the logic of the application. Making too many classes when not needed, gets the code over complicated, and hard to maintain in the future.
    Certainly, but that's a circular argument though. Making too many classes is bad - otherwise it wouldn't be too many. See ?

    Quote Originally Posted by REMIYA
    So personally when I see a $this->retrieve_any_kind_of_data() in a Controller class it makes me shiver
    Why ?

    Quote Originally Posted by REMIYA
    What if I want to place two or three Login boxes on one page?
    If you assemble in the controller-layer, you'll simply create more instances, and assemble them in a composite controller.

    Quote Originally Posted by REMIYA
    And why should the LoginBox class validate the data???
    It should if it's a controller. If it's a pure view component, then it shouldn't. In the previous posts, I have suggested to make it a controller, which naturally places validation in there.

  5. #55
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    It should if it's a controller. If it's a pure view component, then it shouldn't. In the previous posts, I have suggested to make it a controller, which naturally places validation in there.
    There was no way to guess that a LoginBox is a Controller class. Not self explaining names also bring much problems.

  6. #56
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    There was no way to guess that a LoginBox is a Controller class.
    There was - reading the thread

  7. #57
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If I don't see Controller in name ....
    Place a LoginController, if validates LoginModel show LoginBox

  8. #58
    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 dan7
    is it a good please to create an object??
    Yeah, any place within the controller would be fine. Since Login_Model is probably unique, you might create it in a central place to avoid having multiple instances throughout your application. Registry or ServiceLocator would solve this. It's probably not that important though.

    Quote Originally Posted by dan7
    Where I should update the session data, in the controller or in the model?
    That depends on whether you see the session itself as a model or if you use a layer in between. It appears that you're doing the latter - in that case, I would let the model do the updating.

    Quote Originally Posted by dan7
    Is such validation OK? Or should I write additional class for that purpose etc? The example is quite simple, but if the form contains 30 fields, the validation would get much bigger
    Again - you can do validation in controller or in model or in both. It's a matter of taste and the particular context. As a rule of thumb, I generally put validation in the controller, but might move it into the model.
    Since I would suggest that authorization happens in the controller layer, it falls natural to do validation at this place, since different users might follow different rules.

    Quote Originally Posted by dan7
    Is my handling session/some checkings in the Page controller constructor OK? I know I need to check the session and request ASAP, because those things will be needed by other components. And I want to check that only once in my application.
    I suggest you modify your session wrapper to automatically start the session, the first time it's called.

    Quote Originally Posted by dan7
    protected function getUserBox() {
    ...
    The controller should query a model component, and return the appropriate view.
    You could replace $this->is_logged with a call to a model-component. (Model_Login seems like a good candidate), and then skip $this->getSessionData() in the constructor. I think it should be the model's job to do that, when asked by the controller.

    $this->isAjax() also seems a bit misplaced. I'd check the request-type in the execute-method of controller.

    Quote Originally Posted by dan7
    As I'm using some xmlhttp, I just send such requests with additional header, so I can easily check on the server side, if the request is xmlhttp or not without some fancy url vars. I'd like to check that in page.php too and set some variable like is_xmlhttp
    xmlhttp is just a different type of request. So far, we have assumed that each controller takes only one type of request. It's fairly simple to put a switch in the controller to determine the request-type and react in accordance.

    A related problem is global output functions, such as header and exit. I agree that it's dirty to call it from within the controller. Still, better to do it in the controller than in model or view.
    The most common solution seems to be to pass an object in the execute-function of controllers. This object would have an array of headers and other stuff related to the response (most notably charset), and basically act to encapsulate and delay output. Your frontcontroller would then send output from this object after the childcontrollers have been executed.
    In some implementations, this object will also contain $_GET, $_POST etc. variables, and thus basically encapsulate the entire httpcontext. Other implementations split into a Request (input) and Response (output). You might also choose to put the object(s) in a registry, rather than passing it in. (Basically the same story as we touched on earlier).

  9. #59
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    xmlhttp is just a different type of request. So far, we have assumed that each controller takes only one type of request. It's fairly simple to put a switch in the controller to determine the request-type and react in accordance.

    A related problem is global output functions, such as header and exit. I agree that it's dirty to call it from within the controller. Still, better to do it in the controller than in model or view.
    The most common solution seems to be to pass an object in the execute-function of controllers. This object would have an array of headers and other stuff related to the response (most notably charset), and basically act to encapsulate and delay output. Your frontcontroller would then send output from this object after the childcontrollers have been executed.
    I agree on the rest, but here I have a few problems. The current implementaion is not suitable for dealing with xmlhttp, because the childcontrollers are called in the wrong place.

    Having main template as for example:
    PHP Code:
    <?php include("header.tpl.php");?>

    <h1><?php echo $this->__('header'); ?></h1>

    <?php echo $this->getLoginBox(); ?>

    <?php include("footer.tpl.php");?>
    The output starts before echo $this->getLoginBox() is called and thus it brakes xmlhttp responses, because they should contain only som array with data and in this situation they will contain also html output.
    It seems, that I would have to somehow call childcontrollers in the execute method of the front controller and collect views of each component or arrays of output from each component (depends whether it's xmlhttp or not) and after all the collection, I would either send array back to the browser, or the generated view.
    Is that what you meant?
    So, the main controller would look something like
    PHP Code:
    class Page
    {
        (...)
        
        protected function 
    getLoginBox() {
            
    $childcontroller = new LoginBox($this->translator);
            return 
    $childcontroller->execute();
        }

        function 
    execute() {
            
    // so, $loginbox & $otherbox contain either generated views (html)
            // or views in the form of array to send back as JSON 
            
    if (!$this->login_model->isLogged()) {
                
    $childcontroller = new LoginBox($this->translator);
                
    $loginbox $childcontroller->execute();
            }
            
    $otherchildcontroller = new OtherBox($this->translator);
            
    $otherbox $otherchildcontroller->execute();
            
            if (
    $this->isXMLHTTP()) {
                
    $this->sendJson(arra_merge($loginbox,$otherbox));
            }
            
            
    ob_start();
            include(
    'main.tpl.php');
            return 
    ob_get_clean();
        } 


    This assumes, that each of the components can 'add' something to the response, even if the request do not concern them specifically (it might happen). This method is fairly transparent to the request type and each child controller just returns the proper view (either array or html in this case). At the end I check again the request type, and if it's xmlhttp, then I send back the merged response array, if not, I just render the main template and echo the $loginbox etc in its proper places. Does it make sense?

    There is one more issue. What, if I know, that the request to a certain component through xmlhttp should send back data only from this one component? In the example above, I have to execute all components before I send any data back (either json or html). Would it be wise, to send data from within $childcontroller, if I want to skip all other components' checking?

    In the scenario above, I would have to check for xmlhttp in every component, so some of them would probably return only array(), because they operate only on html etc.

    Thanks for help...

  10. #60
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dan7
    Having main template as for example:
    PHP Code:
     <?php include("header.tpl.php");?>
     
     <h1><?php echo $this->__('header'); ?></h1>
     
     <?php echo $this->getLoginBox(); ?>
     
     <?php include("footer.tpl.php");?>
    It is а bad practice to mix HTML and PHP. Don't use echo unless you output the whole webpage!

    Consider using this: Controller->View->LoginPage.

    In Controller:
    PHP Code:
    $view->login_page($_POST['email'],$_POST['pass']); 
    In View:

    PHP Code:
    function login_page($email,$pass){
        
    $html=$this->template("header.tpl");
        
    $html.=$this->template("login.tpl",$email,$pass);
        
    $html.=$this->template("footer.tpl");
        echo 
    $html;
        exit;


  11. #61
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    It is а bad practice to mix HTML and PHP.
    The bad practice is to write spaghetti code. There's nothing wrong in using php in html file (which is a view in my example)

    Quote Originally Posted by REMIYA
    Don't use echo unless you output the whole webpage!
    Please read the previous posts. This is ('echo') used only for template rendering. There's no output to the browser there

    Quote Originally Posted by REMIYA
    Consider using this: Controller->View->LoginPage.

    In Controller:
    PHP Code:
    $view->login_page($_POST['email'],$_POST['pass']); 
    In View:

    PHP Code:
    function login_page($email,$pass){
        
    $html=$this->template("header.tpl");
        
    $html.=$this->template("login.tpl",$email,$pass);
        
    $html.=$this->template("footer.tpl");
        echo 
    $html;
        exit;

    But how does it refer to my examples from earlier posts? I can't see any connection between them and the code above. I don't even have a login page. Login form is just one of the many components on the page in my examples and that's the key point of this thread - dealing with many different components on one page. I don't paste all the previous code in every new post. I just refer to the previous code and paste only the essential parts...

  12. #62
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you just try to defend positions, although they do not bring you anything in return just keep on.

    I'm out.

  13. #63
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't, but you are referring to some general concept of separation while I want to solve a real-life problem which was described in this thread.
    If you can give me a better solution to THIS problem, then I will be really greatful for that, really. If you can tell me how your example applies to my specific situation, then I will be greateful too. The more people trying to help the better.

  14. #64
    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 REMIYA
    It is a bad practice to mix HTML and PHP. Don't use echo unless you output the whole webpage!
    I'd say that it depends. It's bad practice to mix view code with controller (or model) code. But the view can have logic, and PHP is a very good candidate for supplying this. The challenge ofcourse is to keep separation. If you use a different language for the view-logic, you enforce separation in a very strict way. Personally, I don't think it's worth the hassle.

    Quote Originally Posted by dan7
    I agree on the rest, but here I have a few problems. The current implementaion is not suitable for dealing with xmlhttp, because the childcontrollers are called in the wrong place.
    Other content-types than html will normally mean that the page should be structured quite differently. You wouldn't want a lgoinbox in a xml response, for example. This means that there is a forking of the execution path. html-type requests is handled by one branch, while xml-type requests are handled by another. I'd normally implement this as two separate methods on the main controller (Page). Alternatively you could implement two distinct classes, and delegate control to the appropriate one.

    Taking the running example, a fork could look like this :
    PHP Code:
    class Page
    {
        (...)

        function 
    __construct($db$translator$httpcontext) {
            
    $this->db $db;
            
    $this->translator $translator;
            
    $this->httpcontext $httpcontext;
        }

        (...)
        
        protected function 
    getLoginBox() {
            if (!
    $this->login_model->isLogged()) {
                
    $childcontroller = new LoginBox($this->translator);
            } else {
                
    $childcontroller = new OtherBox($this->translator);
            }
            return 
    $childcontroller->execute();
        }
        
        function 
    execute() {
            if (
    $this->isXMLHTTP()) {
                return 
    $this->ajax();
            }
            return 
    $this->get();
        }

        function 
    get() {
            return 
    $this->render("main.tpl.php");
        }
        
        function 
    ajax() {
            
    $this->httpcontext->contentType "text/json";
            return 
    $this->render("main.json.tpl.php");
        }



  15. #65
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Other content-types than html will normally mean that the page should be structured quite differently. You wouldn't want a lgoinbox in a xml response, for example. This means that there is a forking of the execution path. html-type requests is handled by one branch, while xml-type requests are handled by another. I'd normally implement this as two separate methods on the main controller (Page). Alternatively you could implement two distinct classes, and delegate control to the appropriate one.
    One class for both requests is OK, bacause xmlhttp is just a thin layer and covers only specific parts of the application (not all). I usually need to get the data from one component and send it back to the browser. But it may happen, that I would need data from a few components (to update a few places of the GUI at once), so it's good to keep that in mind.

    Now, when I look at your sample code, I have some questions.

    I can give you an example based on the code above. User can send a login request in a standard or xmlhttp way (depends on his browser capabilities). If it's the standard one, then the whole page is re-rendered and sent back to the browser - we got that working already. But when the request is sent through xmlhttp, there should be no rendering. There should be only validation (let's assume it returns false for now) and the json string (actually json encoded array with data) with error message should be sent back to the browser (with appropriate header - header() is another story...).

    This is the simplest case, when the response should consist of data from 1 component only. I think that $this->render("main.json.tpl.php"); is a bit misleading, but that's the place where some magic should happen, for sure. I have no idea what would main.json.tpl.php consist of. Maybe it was just an example, but still, I dont' know how to process this kind of request in the described situation (which would apply to the most of components).

    Thanks

  16. #66
    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 dan7
    I think that $this->render("main.json.tpl.php"); is a bit misleading, but that's the place where some magic should happen, for sure. I have no idea what would main.json.tpl.php consist of. Maybe it was just an example, but still, I dont' know how to process this kind of request in the described situation (which would apply to the most of components).
    Yeah - you'd probably use some other mechanism for generating the json. But basically, json is a form of view - just not an html view.

    Quote Originally Posted by dan7
    I can give you an example based on the code above. User can send a login request in a standard or xmlhttp way (depends on his browser capabilities). If it's the standard one, then the whole page is re-rendered and sent back to the browser - we got that working already. But when the request is sent through xmlhttp, there should be no rendering. There should be only validation (let's assume it returns false for now) and the json string (actually json encoded array with data) with error message should be sent back to the browser (with appropriate header - header() is another story...).
    OK - An implementation of the above could look like the following:

    class/loginbox.php
    PHP Code:
    class LoginBox
    {
        function 
    __construct($db$translator$httpcontext) {
            
    $this->db $db;
            
    $this->translator $translator;
            
    $this->httpcontext $httpcontext;
        } 

        function 
    execute() {
            if (
    $this->isXMLHTTP()) {
                return 
    $this->ajax();
            }
            
    $httpMethod $_SERVER['REQUEST_METHOD'];
            return 
    $this->{$httpMethod}();
        } 

        function 
    ajax() {
            
    $login = new LoginModel($this->db);
            
    $result $login->tryLogin(
                
    $_GET['username'],
                
    $_GET['password']
            );

            
    $encoder = new Services_JSON();
            
    $this->httpcontext->contentType "text/json";
            return 
    $encoder->encode($result);
        }

        function 
    get() {
            return 
    $this->render("loginbox.tpl.php");
        }

        function 
    post() {
            
    $login = new LoginModel($this->db);
            
    $result $login->tryLogin(
                
    $_POST['username'],
                
    $_POST['password']
            );
            
    $this->httpcontext->setRedirect("/index.php");
        }


    Now - since LoginBox is a form, I'd make sure that it's possible to address it directly, aswell as using it as a child controller for the Page class from before. If you're using a frontcontroller with a mapping mechanism, that means that you need an entry that routes request directly to LoginBox. Or if you're using pagecontrollers, you need to create a separate page for the purpose. Either way, you'll use this URI as the action-attribute of your loginbox-form (And as the URI for your xmlhttprequest clientside).
    Let's assume, that your using a pagecontroller style. You now need to create a login.php somewhere in the htdocs dir. The contents would be just the one for index.php :

    login.php
    PHP Code:
    require 'class/httpcontext.php';
    require 
    'class/session.php';
    require 
    'class/db.php';
    require 
    'class/loginbox.php';

    $db = new Database();
    $httpcontext = new HttpContext(new Session($db));
    $controller = new LoginBox($db, new Translator($db), $httpcontext); 
    $httpcontext->content $controller->execute();
    $httpcontext->out(); 
    And for the sake of completeness :
    class/page.php
    PHP Code:
    class Page
    {
         function 
    __construct($db$translator$httpcontext) {
            
    $this->db $db;
            
    $this->translator $translator;
            
    $this->httpcontext $httpcontext;
        }

        function 
    execute() {
            if (
    $this->isXMLHTTP()) {
                return 
    $this->ajax();
            }
            
    $httpMethod $_SERVER['REQUEST_METHOD'];
            return 
    $this->{$httpMethod}();
        }

        protected function 
    getLoginBox() {
            
    $login = new LoginModel($this->db);
            if (!
    $login->isLogged()) {
                
    $childcontroller = new LoginBox($this->translator);
            } else {
                
    $childcontroller = new OtherBox($this->translator);
            }
            return 
    $childcontroller->execute();
        }

        function 
    get() {
            return 
    $this->render("main.tpl.php");
        }

    index.php
    PHP Code:
    require 'class/httpcontext.php';
    require 
    'class/session.php';
    require 
    'class/db.php';
    require 
    'class/page.php';

    $db = new Database();
    $httpcontext = new HttpContext(new Session($db));
    $controller = new Page($db, new Translator($db), $httpcontext);
    $httpcontext->content $controller->execute();
    $httpcontext->out(); 

  17. #67
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks a lot. I've got your point now (I hope )
    I'm not sure if I'll use a page controller or not for those xmlhttp requests, but using front controller shouldn't be too hard now. I'll try that this weekend, I hope.

    My appreciation for all your responses and time taken to help me!!

  18. #68
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    $httpcontext = new HttpContext(new Session($db));
    Actually, this one thing is not obvious to me. Why do you pass session object to the httpcontext? I thought that httpcontext only checks the request type, outputs data (along with header()) and eventually sends redirect (header() again). Or maybe stores some other things like charset or language. I can see some general connection, but is there any use of the session object in httpcontext at all (I'm curious)?

  19. #69
    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 dan7
    Actually, this one thing is not obvious to me. Why do you pass session object to the httpcontext? I thought that httpcontext only checks the request type, outputs data (along with header()) and eventually sends redirect (header() again). Or maybe stores some other things like charset or language. I can see some general connection, but is there any use of the session object in httpcontext at all (I'm curious)?
    Don't put too much into that. You can pass session in as a separate object, but logically, the session depends on the httpcontext in that it uses a session-id stored in a http header (cookie). It doesn't change anything in the example, as such.

  20. #70
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Don't put too much into that. You can pass session in as a separate object, but logically, the session depends on the httpcontext in that it uses a session-id stored in a http header (cookie). It doesn't change anything in the example, as such.
    Yes, I remember about that dependancy (which is a bit transparent). I think, that if there is some additional object like httpcontext, I should move some langugage setting/guessing to this object and then in __construct of frontcontroller do something like $this->lang = $httpcontext->getLang(); ?

  21. #71
    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 dan7
    I think, that if there is some additional object like httpcontext, I should move some langugage setting/guessing to this object and then in __construct of frontcontroller do something like $this->lang = $httpcontext->getLang(); ?
    Yeah - that would make sense.

  22. #72
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi again

    My work is progressing, but I see another issue on the horizon
    I'm wondering what would be the best way to pull data from multiple models
    to render one view. Let's for example assume, that I have tree models - User, Country, Role
    each user belongs to some country and is assigned some role.

    Let's assume, that the action requested by the user is 'edit'.
    So, to show the form, I have to get the data from User model (to show current values), get the data from Country model (to render select box with countries) and get the data from Role model (to render select box with roles).

    What would be the best way to render such a template, that needs data from multiple models?

    Thanks..

  23. #73
    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)
    It's a common point of confusion with mvc, that people tend to equal model layer with model component. The model (the layer) may consist of several distinct components.
    So, the controller should know how to fetch the appropriate model components and pass them to the view. The view will request the model components from the controller. The view doesn't really need to know that the controller queries multiple model components - from what it knows, it may be pulling everything from one source.
    I'd put three different methods on the controller, named getUser, getCountries and getRoles, and then call theese from within the view.

  24. #74
    SitePoint Zealot
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    108
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks a lot. I'll follow that.

    I'm not quite sure how much work should my procedural template do. I could just iterate over the result of getCountries and build selectboxes, but in case of getUser, I would have to assign the result to some variable first. I'm not sure if it's wise, to make such assignment in the template view itself?

    The other thing is escaping data etc - doing it in the template may result in reading complexity in the future.. So maybe the view class would be a better idea in this case?

    Thanks

  25. #75
    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 dan7
    I'm not quite sure how much work should my procedural template do. I could just iterate over the result of getCountries and build selectboxes, but in case of getUser, I would have to assign the result to some variable first. I'm not sure if it's wise, to make such assignment in the template view itself?
    I think variables are allright, but it's borderline. I'd definately say that the view should only get primitives, such as scalars, arrays and valueobjects - not complex model components.

    Quote Originally Posted by dan7
    The other thing is escaping data etc - doing it in the template may result in reading complexity in the future.. So maybe the view class would be a better idea in this case?
    I put stuff like htmlentities() in the template - it's definately a view responsibility. I don't think it clutters too much.


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
  •