SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 70 of 70
  1. #51
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by sunwukung View Post
    matter of opinion really - depends if you're a purist, or a pragmatist. In Zend you can pass the form object to the view from the Controller i.e:

    HTML Code:
    $form = new Blah_Form;
    if($_POST){
    //validate, get messages etc etc.
    }
    $this->view->form = $form;
    Changes to the form are updated dynamically in the view.
    Does that help though? You still need to check in the view whether the form is submitted and valid, and you still need to do it before you save the data from it.


    As for "emulation"... that's not really what's happening. I'm not advocating storing the model in the session here or anything.

  2. #52
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Does that help though? You still need to check in the view whether the form is submitted and valid, and you still need to do it before you save the data from it.
    You don't HAVE to do that in the view (in Zend):

    http://framework.zend.com/manual/en/...uickstart.html - see Get Error Status

  3. #53
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    But then you have display logic in the controller and lose reusability.

    Deciding which view to display is display logic in itself.

    Here's my completely reusable and extendible FormView class which handles all this and contains a switch for whether to display form fields or plain text.

    PHP Code:
    interface FormModel {
        public function 
    getForm();
        public function 
    isValid(Form $form);
        public function 
    isSubmitted(Form $form);
    }

    class 
    FormView extends View {
        const 
    EDIT 1;
        const 
    DISPLAY 2;
        
        protected 
    $submittedView;
        protected 
    $form;
        protected 
    $model;
        protected 
    $mode;
        protected 
    $appendSubmitted false;

        public function 
    __construct($templateView $submittedViewFormModel $model$mode self::EDIT) {
            
    parent::__construct($template);
            
    $this->addScript('js/form.js');
            
    //The view to use when the form has been submitted (and is valid!)
            
    $this->submittedView $submittedView;
            
    $this->model $model;
            
    $this->mode $mode;
        }
        
        protected function 
    run() {
            
    $this->form $this->model->getForm(); 
            
    $this->template->addHook($this->hook->form($this->form$this->mode));
            if (!
    $this->mode == self::DISPLAY && $this->model->isSubmitted($this->form) && !$this->model->isValid($this->form)) $this->template->showSection($this->form->name '_errors');
            foreach (
    $this->form->getErrors() as $error$this->template->appendSection($this->form->name '_error', array('error' => $error));
        }
            
        public function 
    output() {
            
    $this->run();
            
    $this->postProcess();
            if (!
    $this->mode == self::DISPLAY && $this->model->isSubmitted($this->form) && $this->form->isValid($this->form)) {
                if (
    $this->appendSubmitted) return $this->template->output() . $this->submittedView->output();
                return 
    $this->submittedView->output();
            }
            else return 
    $this->template->output();
        }


    You can pass it any model along with any template and another view which is used when the form is submitted.

    This handles 99% of forms used on all my projects, those which don't are simple extensions of this class because they need to do something else for example add additional data to the view, in which case they extend the view and add more data to the template in the postProcess() method I have available in all views.

    I have similar views for listing records and pagination.

  4. #54
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This just demonstrates that there is more than one way to skin a cat. Just look at the different implementations of core design patterns in CodeIgniter, Zend, Cake and Symfony (to name a few).

    Each method has consequences that are not always evident on first review.
    These consequences are often discovered in the context of the actual project.

    Should we always use an ORM for example, or is it simply a choice available to us? In some instances, Transaction Scripts are better than Rich Domain Models, in others, Active Record is more efficient to deploy, although it results in the tight coupling of Models and DAOs. Registry pattern is evil, but sometimes it's a lifesaver. You pointed out yourself that querying the Model from the View was a workaround, but it increased productivity. Should I deploy a full stack MVC framework for a 5 page brochure site. When you have a hammer...

    Design patterns ultimately should enable us to complete a task, not mire us in dogma that prevents us from doing so.

  5. #55
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Of course, but design patterns are there and become accepted patterns because they are tried and tested. It also forms a sort of standard making it easier for other developers to pick up your code and work with it. All methods have advantages and disadvantages.

    I'm only posting in detail about my own opinions here because several people basically told me I was wrong for giving the view access to the model, even though it's standard practice in MVC. I just wanted to provide some examples so people can see the pros/cons of this method as many people here just dismissed it out of hand on no real basis (or even gave a real explanation why...) other than it not being what they're used to.

    I'm not saying it's the best solution for every scenario, but that it does have some distinct advantages (mainly reusability) over other methods.

  6. #56
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "I was wrong for giving the view access to the model"

    In the context of the MVC pattern (as I understand it), granting two way access IS wrong. In the context of N-Tier, granting ANY access is wrong. In terms of reusability, it may not be. Should you honour the pattern at the expense of productivity?
    Discuss...

  7. #57
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,526
    Mentioned
    83 Post(s)
    Tagged
    3 Thread(s)
    Here I thought that the view should accept the data that's provided to it and only reach out and touch other view-related material.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  8. #58
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    2 way access was wrong, and I provided two alternative solutions

    Passing the model to the view for read access is entirely correct in MVC.

  9. #59
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    How are you going to work out what type of customer you're dealing with? $purchaseLimit = CustomerType.CORPORATE.limit; wont work... you'd need a 100 block if-else to work out the correct type...
    I realize the thread has gone away from this, but I wanted to touch on this for just a moment, to perhaps clarify your confusion.

    In this case, CustomerType (this looks like Java or C#) would likely be an Enum, which would be defined separately. For example:

    Code Java:
    public enum CustomerType {
     
        CORPORATE {
            @Override
            public int getOrderLimit(){
                return 1000;
            };
        };
     
        public abstract int getOrderLimit();
    }

    Would be a way to define the order limit without needing switch/if statements everywhere. It's actually a much more elegant way to do it, though I don't know that PHP has anything similar.

  10. #60
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sunwukung View Post
    Tom is right, in terms of MVC proper, the view does have access to the model, but it's a one way street - but...

    "In others, the view is automatically notified by the model of changes in state (Observer) which require a screen update."
    I think that's where the MVC approach people are talking about here breaks down for me - since I would never put input handling in the view. For me, view is just there to SHOW things.

    I can see how people coming from visual programming backgrounds could think that way - it's probably part of why I can't do visual programming (I can hand code x86 assembly, I can't use visual programming to save my life) since I know how it ACTUALLY works under the hood - and while the visual interface may hide it from the people pretending to program by dragging stuff around, "view" is called by the controller under the hood, as is keyboard handling...

    Take the Windows API for example - wm_actvate, wm_close, wm_create, wm_mousemove, wm_keydown - that's all stuff I consider to be handled by the CONTROLLER, not the View. That's user input. wm_paint is the view, and guess what it's handled by? The controller loop - aka your WindowProc. I'm used to thinking of the loop or main input handler like WindowProc being the controller, since it's controlling EVERYTHING - calling view OR data handling as appropriate to the user input. The data wants the view changed, it puts wm_paint on the control stack.

    If you are just using the controller to set up values at startup, what the **** is it even CONTROLLING?!? That's not a controller, that's a LOADER. You have it not "controlling" a damned thing... hence why I'd have user input handled by the controller - makes even more sense in php since all user input occurs BEFORE the code even starts running - why would you even be sending it to the view first in the first place? Much less what the user sends for input could change what model AND what view is loaded - you put it in the view when user input can determine what view is loaded -- that doesn't make a hell of a lot of sense either.

    Though I do a lot of programming where the two (view and model) are unchained, operating independantly of each-other for certain tasks...

    Quote Originally Posted by sunwukung View Post
    Winged Spider is arguing from the perspective of n-tier application design, which is more appropriate to the web - but is not MVC.
    Which for web development the three tier system is closer to what I'm saying - though inside the program presentation would go last since until you figure out what the user asked for and pull it up, the presentation has nothing to do.

    Besides, putting presentation/view as the last thing called AFTER data/model makes more sense should your 'model' suddenly want to send cookies or response headers - since once your view starts output, it's too late to send those.

  11. #61
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yikes. No wonder people get confused about MVC with all this conflicting (and erroneous) information.
    Quote Originally Posted by sg707 View Post
    Http requests -> Master Front Controller -> Business Controller -> Master Front controller -> retrieve and render view template -> Master Front Controller -> client's browser.
    MVC has three distinct parts ... you list two kinds of Controllers, a template and no Model!!! I don't know what "Master Front Controller" and "Business Controller" are? Typically in PHP you will have a Front Controller that dispatches an Action Controller. Technically the combination of both is the Controller in MVC. In practice, the Action Controller is often referred to as the "Controller" since those are the things you work with most.
    Quote Originally Posted by sg707 View Post
    Definitely model should not contain any critical business logic. If it's doing minor validation like length or require check then it's justifiable. But, no processing like storing data into a DB is a definite NO NO!
    Business logic is the whole point of the Model! The Model is what contains all the stuff in the Domain that makes the application what it is. Definitely push as much domain logic into the Model as you can and keep the Controllers minimal.
    Quote Originally Posted by Winged Spider View Post
    Views accessing datalogic and the DAO? Insanity!

    That is certainly not MVC. MVC is pretty clear on who does what and I'm pretty sure Java, .Net, and possibly RoR/Django guys would have a heart attack if a Model accessed the database.
    ...
    A model being coupled to your database layer is really bad news.
    If the Model is not supposed to "access" or be "coupled" to the database ... then what is? The View? The Controller? These are the kind of statements that confuse people about MVC. The Model is certainly where access to persistent data should occur. In PHP it can do that through a DAO or directly. It is up to you whether you want to add a Datasource layer below your Model layer. That is irrelevant to MVC which only says the Model is not in the Presentation layer with the View and Controller. And that separation is the important one in MVC. As to whether the Controller or View should "access" the Model -- it is up to you. Both Controller and View are in the Presentation layer and can have a dependency on the Model.

    sunwukung, listen to what TomB is saying. He is leading you in the right direction.
    Christopher

  12. #62
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,381
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Honestly though it would be very fascinating if we all could seat in 1 room w/ big white board. I think what's going on here is that people read the post word by word. Like the saying, 1 picture = 1000 words. For the above posts. Of course there is a model!!! Why would I mention modelDAO if it's not involved in the process. Model is what gets passed to the controller. That's like saying I will never get dynamic content from the server.

  13. #63
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,526
    Mentioned
    83 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by sg707 View Post
    Like the saying, 1 picture = 1000 words.
    you mean, like this?



    source: The Model-View-Controller (MVC) Design Pattern for PHP

    Or like this?



    source: Detailed Process-Request Activity Diagram
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  14. #64
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,381
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    Yup but w/ a person explaining step by step. Body language is 70% of the communication

  15. #65
    SiteP0int Weazle hooknc's Avatar
    Join Date
    Dec 2004
    Location
    Socialist Republic of Boulder
    Posts
    937
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    Yup but w/ a person explaining step by step. Body language is 70% of the communication
    Congrats on your 1000th post sg707!
    baby steps... baby steps...

  16. #66
    SiteP0int Weazle hooknc's Avatar
    Join Date
    Dec 2004
    Location
    Socialist Republic of Boulder
    Posts
    937
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint View Post
    If the Model is not supposed to "access" or be "coupled" to the database ... then what is? The View? The Controller? These are the kind of statements that confuse people about MVC. The Model is certainly where access to persistent data should occur. In PHP it can do that through a DAO or directly. It is up to you whether you want to add a Datasource layer below your Model layer. That is irrelevant to MVC which only says the Model is not in the Presentation layer with the View and Controller. And that separation is the important one in MVC. As to whether the Controller or View should "access" the Model -- it is up to you. Both Controller and View are in the Presentation layer and can have a dependency on the Model.
    I've only skimmed this thread and maybe this weekend I'll read it fully, but here are some points about mvc...


    Domain Model != MVC Model

    Sure a Domain Model object could be used by a view but not always and in some cases would be completely inappropriate. I prefer making specific model classes and instances for specific views. In Java with Spring MVC these are called form backing objects and they should then either be the 'model' or contain the other model classes for the specific view. For instance when displaying an html table with information from many different Domain Objects, it would be more appropriate to produce a Table Model that has the correct information for the table and then pass that Table Model to a Table Component to render the Table Model.

    Please look at Java's implementation of Swing for a very nice example of MVC.


    Validation.

    I would recommend having validation external of your domain objects. Different controllers will/can require different validation.

    Break validators down into separate classes that only validate one rule. Does the attribute have a value? Is the attribute a number? Is the attribute already in the database? It is acceptable to have database access in a validator, but perform those checks last.

    Then build a controllers validator from chaining multiple smaller validators together. Performing required checks first and returning any errors, then data validation and returning any errors, and then finally your validators that require data access.


    Domain Models and Persistence

    I really recommend against having database access or logic in your Domain Model. Your Domain Model is just that, the definition of your domain. It is that simple. I've hardly ever heard of anyone saying that our customer access the database directly to get their data in any requirements meeting I've been in. That being said the Domain Objects in a way represent the problem and attempting to keep the code as cleans as possible to explain exactly what the problem is, is, important. Having persistence logic in your Domain Model will muddy the ability to see the problem.

    HOWEVER, if you wish to implement lazy loading or some other type of database improvement consider proxying your classes with wrappers that will handle the database code for you. This of course implies that you've programmed using interfaces for your Domain Model classes. Luckily for us in the Java world we have Hibernate to take care of this problem.
    baby steps... baby steps...

  17. #67
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by hooknc View Post
    I've only skimmed this thread and maybe this weekend I'll read it fully, but here are some points about mvc...


    Domain Model != MVC Model
    Isn't that pretty much what arborint said? Anyway, I wanted to quote it because not appreciating this distinction seems to be where people get confused with MVC.

    However one thing that needs to be made clear here is: MVC doesn't specify how your models (or controllers or views for that matter) work, only that they're the part of the application that deal with the domain logic nor does it define how the model interacts with the database. Some ways are better than others, of course... but the implementation is nothing to do with MVC.

    I don't disagree with anything you said, but MVC architecture has no bearing on the merits of Data Mappers vs Active Record, where validation should be done or even OO vs procedural programming.

    The problem I have is, getting caught up on these implementation details appears to be where people get confused because it makes MVC seem to be a bigger, more daunting and confusng topic than it really is and it detracts from the actual MVC related design decisions you need to make. Not that I've not wandered into implementation detail myself of course.

  18. #68
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On reflection, it's certainly preferable for aspects of your model to be directly accessed from the View. (When I say access, I mean read, not written). As TomB pointed out, passing specific model output variables into the view from the controller tightly couples those layers. This coupling will prevent "widgetizing" of your models/views.
    In long term projects, adding new modules to an application requires integration of new features into an existing code base. The coupling of the model and controller will make it much harder to "drop" modules into place, without causing a ripple effect throughout your existing controller logic.

  19. #69
    John 8:24 JREAM's Avatar
    Join Date
    Sep 2007
    Location
    Florida
    Posts
    1,508
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    JREAM - your use of defines makes me cringe, especially given that you put many security values in them:
    Uhg... Learning from Wordpress' example I see.

    Well I had been parsing an INI file (directory protected by .htacces) previously inside of a Database Construct, I wanted to simplify it with this, I haven't considered how these Constants are flawed, I just wanted an easy way to transfer Data from one spectrum to another. I guess I'll have to rethink this :P

    I don't look at WordPress' back-end I didn't know they did that lol.

  20. #70
    SitePoint Member strokem's Avatar
    Join Date
    May 2010
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just wondering, since i am quite new in MVC, but can anyone tell me, is CodeIgniter is a good model for MVC structure?
    Last edited by DaveMaxwell; Jun 21, 2010 at 09:37.


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
  •