SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)

    Question Still asking questions gentlemen...

    I am still looking at PHP in my time off to get better familiar with it and I need help understanding a concept. This involves a controller / handler / item pattern. I'm not sure what the name is, but I've seen this elsewhere. At least something similar.

    Let's say I wanted to completely modularize my application into the following things:

    Controller [Singleton] // pivot class

    RequestHandler [Singleton?] // handles form and query string requests
    DisplayHandler [Singleton?] // handles requests to display output
    QueryHandler [Singleton?] // handles requests to the database

    Requests [must derive custom classes such as NewArticleRequest]
    Displays [must derive custom classes such as NewArticleDisplay]
    Querys [must derive custom classes such as NeewArticleQuery]

    Such that the following code is possible...

    Code:
    //setup controller and handle requests here
    include('initialize.php');
     
    $header = new HeaderDisplay(); // may use custom query objects to get data
    echo $header; // uses __toString;
     
    // destroy controller and clean up
    include('terminate.php');
    But I get lost. Where does the controller fit in? Can somebody please explain this whole pattern to me? Do I have it completely wrong?

  2. #2
    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)
    Still very PHP4 based, but you might want to look through the WACT examples as a project that "get patterns right".

    HTH
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  3. #3
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Well...I did as you said and looked at the code you linked to and while it looks nice I didn't understand most of it because key files "required" into the sample code weren't in the sample tree. Can you actually EXPLAIN the model to me? WHen I look at code like the above I can't "see" the big picture.

  4. #4
    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)
    The main body of WACT code can be view directly from the cvs repository here. The controller architecture underwent a complete revision this fall, and I have only written a couple of application using it since then, so I may not be the best "expert" to query on the issue, but I will give it a stab. Jeff has a great MVC write up here.

    In an MVC architecture, the M is your Model, were all of your "Business Logic" is capture. This includes most of the persistant data access (i.e. storing stuff in a db) and any "rules" unique to the web application you are developing.

    V is View, and in WACT is handled via a Template system using the CustomTags.

    C is Controller, and it's responsibility is marshaling the HTTP request, determining which view to display or other action to take (perhaps form processing). In WACT, the controllers are built using the Composite pattern, meaning controller can have sub-controllers which can in turn have sub-controllers, and processing of the request can descend that composite structure until someone decides to take action.

    Of the three components of Model-View-Controller, Models are almost entirely custom logic you have to write for your application. Views are what transforms the results of querying your Models to output for the browser, and therefore a significant portion of the View logic is in Templates systems, like WACT templates or Smarty. The Controller portion is the handling of the HTTP request, and is the chunk of MVC most likely to be what any individual library that claims to be an MVC framework deals with (see MVC Frameworks written in PHP).

    HTH

  5. #5
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Well I already have a custom templating system (it was the first thing I wrote) using xml with custom namespaces for certain tags. Anyway, if I get this right...

    the following would be models
    Code:
    class UserModel {
     
    public function __construct($id) {
    // fetch the user based on id and set class var to $results
    }
     
    public function fields() {
    // return the fields array
    }
     
    }
     
    class NewUserModel {
     
    public function __construct($field_values) {
    // init some class levels vars
    }
     
    public function commit() {
    // attempt to add the row and return a success state
    }
     
    }
    Validate that before I go further....

    [NOTE: Regardless of language, this is extremely helpfull to me as I think I missed out somewhere along the line...]

  6. #6
    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)
    Domain modeling is a very complicated subject, and I am by no means an expert. If I put on my "lastcraft" hat, the first thing Marcus would critisize you is the vauge notion of a "User". I am assuming what you are really talking about is a "Login" to your web site? (a "user" the real person might actually have several "login" identifications to a site, right?)
    Does your login just act as a blanket access control to content, or is there a more fine grained access control assosiated with it?

    PHP Code:
    class Login {
      public function 
    checkPassword($password) {} //boolean
      
    public function changePassword($old$new) {}
      public function 
    getAccessLevel() {}
      
    //...
    }
    class 
    LoginFinder {
      private 
    $dbconn;
      public function 
    __construct($dbconn) {}
      public function 
    findByName($name) {} // return an instance of Login
      
    public function findRecent($limit=20) {} // return array of logins, perhaps for "most recent registrations" list
      //...
    }
    class 
    LoginRegistrar {
      private 
    $dbconn;
      public function 
    __construct($dbconn) {}
      public function 
    create($name$passwd) {}
      public function 
    suspend($name) {} 
      public function 
    delete($name) {}
      
    //...

    Not sure if that really helps or not.

  7. #7
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The naming / factoring of users / abilities is driving me crazy as well, so I'll add to the confusion This is what I'm working on, although it is by no means perfect.

    User is more or less a data holder.

    Parts of it (UserServicesAgent!) seem really wordy. I'm not sure of a naming convention / layering method thats concise without being really abstract.

    PHP Code:
    <?php

    $User 
    =& new User();
    $User->set('name''Phil');
    $User->set('password''pw123');

    $UserServicesAgent =& new UserServices($DB);
    $UserServicesAgent->register($User);


    $LoginToken =& new LoginCard(userpass)
    $User =& UserFinder::by_login($LoginToken);

    $User->set('address''123 Sunshine Dr'); // I actually used to live on 275 ;)
    $UserServicesAgent =& new UserServices($DB);
    $UserServicesAgent->modify($User);


    $User =& UserFinder::by_id(int id);
    $UserServicesAgent =& new UserServices($DB);
    $UserServicesAgent->delete($User);


    // AbilityControler?  Authenticator?  AuthServer ?  Permissions?
    $AbilityMaster =& $PermissionFinder::by_user($User);


    ?>

  8. #8
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Hehe. Well what I was going for here was just to validte whether I got the concept of a 'model' being a unit of logic only. Most likely, but not always, intereacting with the db. In my example I simply used 'User' to represent a single row in the 'Users' table. It could've been anything and wasn't meant to be concrete. You did manage to touch on my next question which was: how do I properly determine what functions should be grouped into logical units as opposed to others? For now though, let's move on instead. We can come back to this later, once I get the "basic idea' begind all three elements.

    My understanding of a controller is nothing more than a repackaging of the switch mentality. In essence, the 'main' controller would test the querystring and determine if any inserts, updates, or deletes need to occur before any display and might even spawn another controller to handle the exact action. Once that step is done the main controller continues and determines what to actually display.

    My understanding of the view is simply that. It's a rules free, show the data you have any way you want because at this point you don't have anything you shouldn't.

    Yeah.... I know that stunk for a description, but in a VERY basic nutshell, am I on track so far???

    Forgive the typos....I'm in the dark and I don't type so well if I can't see the board.

  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)
    Quote Originally Posted by Serenarules
    My understanding of a controller is nothing more than a repackaging of the switch mentality. In essence, the 'main' controller would test the querystring and determine if any inserts, updates, or deletes need to occur before any display and might even spawn another controller to handle the exact action. Once that step is done the main controller continues and determines what to actually display.

    My understanding of the view is simply that. It's a rules free, show the data you have any way you want because at this point you don't have anything you shouldn't.

    Yeah.... I know that stunk for a description, but in a VERY basic nutshell, am I on track so far???
    I think you are on the right track. There is perhaps a bit more to it. I include maping all HTTP requests varaible, i.e. a Model should never access $_GET['anything'], etc. Instead this should be brokered through the controller (i.e. somewhere inside the controller logic you would do: $account->deposit($request->get('amount'); , where the controller know enough about the View to know where a form was submitting data, and enough about the model to know what methods to access to pass the HTTP information to). I typically structure a controller so you have "actions" e.g. short command scripts which plug into your framework and perform these mappings. The most commonly used "action" is invariably my "showView" action.

    HTH

  10. #10
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Alrighty then. Moving on. To put all this together....

    RequestController (Always present)
    --ActionController (created only if isset($_GET['a']))
    ----Action1 (based on 'a' value)
    ----Action2 (based on 'a' value)
    ----...
    --ViewController (created only if isset($_GET['v']))
    ----View1 (based on 'v' value)
    ----View2 (based on 'v' value)
    ----...

    Both views and actions may use the applications models and singleton helpers during thier lifetime. Since a processed action may not require a display, but rather a redirect we don't explicitly create a View. Again, this was very simplistic. I just need to validate my understanding of the overall concept at this point.

  11. #11
    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)
    That seems a reasonable approach to me.

  12. #12
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Damn, I actually understood something.


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
  •