SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Montreal
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question MVC : View Childs ?

    I'm new to the design pattern concept, and I am currently building a (very big) portal website using the MVC pattern. In all the examples of MVC Ive seen, there was only one class used for the view. Heres my question : If the View class becomes too big, is it okay (does it respect the MVC pattern, is it good programming practice) to have generic functions (i.e. template) in the View class, then have child classes for each different purpose ? Example :

    PHP Code:
    class View {

        function 
    getTemplate($Template$SR=null) {
        }
      
        
    etc...
    }
    class 
    Authentification extends View {

        function 
    UserLoginForm() {
        }
       
        function 
    AdminLoginForm() {
        }
        
        
    etc...

    Also, if this is ok, what kind of grouping would I be better off using
    e.g :
    Grouping 1
    class View
    |- class Authentification
    |- class News
    |- class Groups
    +- etc...

    Grouping 2
    class View
    |- class Forms
    |- class Content
    |- class Forum
    +- etc...


    Keep in mind that this site is huge - the reason I do this is to save me from 10,000 line classes

    Thanks,

    Louis

  2. #2
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Denmark
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why don't you do some caching work (with DB backend as storage for the (x)html, or whatever you use) - that way you should be able to save yourself both time and lines

    If it is in context with the pattern, I don't know. But erhm, patterns is here to help us solve common problems, they are code-guidelines, not godly answers

    just my 50 cent

  3. #3
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    10,000 lines ? That's not huge, just a tiddler

    There is nothing wrong with haveing a base View class to do the housekeeping, and extending more functionality such as an authentication View.

    I used this approach myself, though now I just have the one class which fetches required files, and does some administrative work on them, ie rendering.

    For outputting dynamic data, I 'append' another View class altogether to the base class, thus the base class can administer one or more Views, yes ?

    Think this is the Composite View, from what I can tell

  4. #4
    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 is a topic witch people tackle quite differently. you should be aware not to use a too tight coupling of your views. This implies that inheritance is bad, aggregating better. (eg. use a composite view).

    or ... that's my experience anyhow.

  5. #5
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This implies that inheritance is bad, aggregating better.


    Been suggested that an Decorator offers more options over Inheritance as well.

  6. #6
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Montreal
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your replies, could anybody point me to a resource on Aggregating/Composite View pattern for PHP (I have only find them for Java)

    Thanks,
    Louis

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

    Aggregating? Learn UML.

  8. #8
    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 Widow Maker
    Been suggested that an Decorator offers more options over Inheritance as well
    yep, that's what i meant.

    Quote Originally Posted by louism
    could anybody point me to a resource on Aggregating/Composite View pattern for PHP
    This is a nice page on decorators : http://www.google.dk/search?q=cache:...22hm/lect2.htm

    you may argue that "decorator" is just a patterns-buzzword for something very basic to oop - namely combining two classes into one, by letting a third object inherit from one of them, and having the other as a property.

    eg :

    PHP Code:
    class one {
        function 
    foo() { ; }
    }

    class 
    two {
        function 
    bar() { ; }
    }

    class 
    three extends one {
        function 
    three() {
            
    $this->_two =& new two();
        }
        function 
    foo() { return parent::foo(); }
        function 
    bar() { return $this->_two->bar(); }

    in the above code, one and three are related through inheritance, whereas one is related to two through aggregation. The latter relation is less difinite than the former, witch is something you would want in theese cases. (you could easily switch out two with something else, like four)

  9. #9
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    An important distinction with a Decorator is that the entire public interface of the class being decorated is replicated in the decorator. This important distinction allows the Decorator to be an exact stand in for the decorated class, a behavior you do not get with simple aggregation.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  10. #10
    SitePoint Enthusiast
    Join Date
    Aug 2004
    Location
    Rome, Italy
    Posts
    28
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    About Composite Views you could find interesting these two threads:

    http://www.sitepoint.com/forums/showthread.php?t=181682

    http://www.sitepoint.com/forums/showthread.php?t=189658

    Ciao.

  11. #11
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Montreal
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks everyone. Now I understand how simple aggragation is
    What do you think about this approach :

    Simple Controller :
    PHP Code:
    <?php
    include 'Library.php'// include requried classes (models, etc.)
    $Login View::Factory('viewUser');
    $Login->Login();
    ?>
    View (view/View.php) :
    PHP Code:
    <?php
    class View {
        
       
    /** Factory
        *
        * Returns a child view object.
        *
        * @author Louis Mullie
        * @params $Class string name of the class to be instanciated
        * @return Object child class
        */ 
        
    function &Factory($Class) {
        
            require_once 
    $Class.'.php';
            return new 
    $Class;
        
        }

        
    // other generic functions for building tables, forms, templates, etc.
    }
    Child view (viewUser.php) :
    PHP Code:
    <?php
    class viewUser extends View{
        
       function 
    Login() {
         
    // print login form
       
    }
    }
    ?>
    Last edited by louism; Aug 24, 2004 at 09:17.

  12. #12
    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 sweatje
    An important distinction with a Decorator is that the entire public interface of the class being decorated is replicated in the decorator. This important distinction allows the Decorator to be an exact stand in for the decorated class, a behavior you do not get with simple aggregation.
    I tend to use aggregation, usually with a decorator base class, eg:

    PHP Code:
     /*
         CLASS IteratorDecorator
     
         Iterator decorator base class.
     */
     
    class IteratorDecorator 
     
    {
         var 
    $it;
         var 
    $current;
     
         
    /*
         */
         
    function IteratorDecorator(&$it)
         {
             
    $this->it =& $it;
         }
     
         function 
    reset() 
         {
             
    $this->it->reset();
         }
     
         
    /*
             return (bool)
         */     
         
    function isValid() 
         {
             return 
    $this->it->isValid();
         }
         
         function 
    next()
         {
             
    $this->it->next();
         }
     
         
    /*
             return (mixed)
         */ 
         
    function &getCurrent() 
         {
             die(
    'Method not implemented.' __FILE__ ' | line ' __LINE__); 
         }
     
     } 
    I think this is more flexible. An aggregated iterator decorator can be used with any kind of iterator but if you created the decorator by extending, say, an ArrayIterator, you can't re-use the same class with other types of Iterator.

  13. #13
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I think this is more flexible. An aggregated iterator decorator can be used with any kind of iterator but if you created the decorator by extending, say, an ArrayIterator, you can't re-use the same class with other types of Iterator.
    Right, and you are using the Decorator class the way I intended from my previous comment, i.e. you are proxying all of the public methods of the Iterator (your decorated class) to the aggregated object. I was trying to contrast this with simple aggregation, e.g.
    PHP Code:
    class SomeModel {
      var 
    $db//database connection
      
    function SomeModel(&$db) {
        
    $this->db =& $db;
      }
      function 
    SomeQuery() {
        
    $this->db->query($sql); //...
      
    }


  14. #14
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Rgr - must have picked you up the wrong way.


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
  •