1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Development Class names and structure for new PHP app

Discussion in 'Software' started by OneSeventeen, 22 Aug 2007.

  1. OneSeventeen

    OneSeventeen Oooh Shiny!

    Joined:
    3 Apr 2002
    Posts:
    3,454
    Likes Received:
    2
    I'm writing an intranet for my work using PHP, and I've got a very good idea of what I want it to do. (In fact, I have it working using poorly written scripts as a "proof of concept" and it works great)

    The idea is I would have 3 major portions of the code:
    1. Authentication class to authenticate against our Domain Controller and contain user details and whatnot.
    2. Template class to know which scripts to load based on the URL
    3. Actual stand-alone scripts t hat get loaded by the template system

    Since this is a management system for scripts, I'm thinking of calling the template class "SKMS" for "Script Kiddie Management System". (Since SMS is already a well known acronym)

    Then, I'm thinking of having the authentication class simply be called "ADAUTH" since it is an Active Directory authentication class.

    All of the stand-alone scripts would be stand-alone, so they don't really matter, EXCEPT I want to be able to easily interact with the template, so I'm thinking of adding a bunch of data retrieval, storage, parsing, and display functions to the SKMS class.

    So the SKMS class would have this rough structure:
    • Authentication functions, that rely on the AUTH class, which extends ADAUTH (so I can make common methods in AUTH that access "ADAUTH", so if I want to change authentication methods in the future, I just change the AUTH class, not all the random bits of the SKMS class)
    • Database functions, that rely on the DATA class, which extends MDB2 with some super-specific database interaction functions
    • Permissions functions that use the database and authentication functions to manage whether or not the user can see the page
    • Admin functions that make it possible to store new script/permissions/page status/etc in the database (and therefore add new scripts to the intranet, disable scripts temporarily, etc.)
    • Rendering functions, that simply spit out content in a safe manner. (So it can run through and strip disallowed tags and add in various tags based on the entry method...)

    Any scripts that would be loaded would have access to the public methods of the class, so I could write a quick script that would use the class to pull data and display it in a certain way on the page.

    Any ideas of what I'm doing that might be horribly wrong?

    Should I separate things more, combine things more? Is it better to have one massive all-encompasing class that does authentication, permissions, database, and template stuff? Or should I have what I mentioned earlier, and have 3 main classes, database, authentication, and the massive class that ties it all together and displays it?
     
  2. simon w

    simon w What's a Dremel?

    Joined:
    3 Nov 2003
    Posts:
    1,302
    Likes Received:
    0
    Until/if we get namespacing in PHP6, a common class naming convention for classes/filenames is,

    PHP:
    class [package]_[classname] extends [package] {}
    Where underscores represent package boundaries and are translated to directory separators in an autoloader. Checkout the Zend Framework and their coding standards for working examples of this.

    I'd flip the inheritence direction. Data is the parent class with a factory method and abstract methods for DB server specific calls. Data_Mdb2 then extends Data and overrides the abstract methods.

    E.g.

    PHP:
    class Data // filename = ./Data.php
    {
        protected 
    $dsn ''// protected so that Data_Mdb2 can access if needed

        
    function __construct($dsn)
        {
            
    $this->dsn $dsn;
        }

        abstract function 
    execute($query) {}

        static function 
    getInstance($dsn)
        {
            
    $driver //get server type from $dsn
            
            
    $driverClass __CLASS__ '_' ucfirst($driver);

            return new 
    $driverClass($dsn);
        }
    }

    class 
    Data_Mdb2 extends Data // filename = ./Data/Mdb2.php
    {
        function 
    __construct($dsn)
        {
            
    parent::__construct($dsn);
        }

        function 
    execute($query)
        {
            
    //Mdb2 specfic implementation for running a query
        
    }
    }

    $dsn // load from config file

    $db Data::getInstance($dsn);

    $result $db->execute('SELECT ...');

    So to migrate to MySQL, just create Data_Mysql (./Data/Mysql.php) and implement the abstract methods and update your config file with the new dsn. With this approach you should not need to change any existing code.

    No, have the MVC and auth logic abstracted away into sperate classes. Your view class only needs to know if a user is allowed to access a given page, not how the authenication check is done.

    Sounds like your writing your own mini-framework. Have you considered using a 3rd party framework instead?
     
    Last edited: 24 Aug 2007
  3. OneSeventeen

    OneSeventeen Oooh Shiny!

    Joined:
    3 Apr 2002
    Posts:
    3,454
    Likes Received:
    2
    I know this reply is a little delayed, but I've finally carved out some time each day to work on my frameworkish project. (Not using other frameworks because I need something different. More specific but less complicated.)

    Funny enough abstract classes never really made a whole lot of sense to me until now...
    Now the question is, what is the difference between an abstract class and an interface?

    progress of the project can be monitored at http://code.google.com/p/shoehorn (the front page has links to the blog, discussion, etc.)

    So how is an interface different from an abstract class?

    EDIT: One more question:
    Since this is for a specific application, would it be more sensible to add even more to the class name, such as:

    abstract class Shoehorn_Data

    class Shoehorn_Data_Pgsql extends Shoehorn_Data

    Since I'm planning on adding specific methods for retrieving specific chunks of data pertaining to my application?

    I don't want to make generic abstractions, because I want to be able to take advantage of the various database features, so Shoehorn_Data_Pgsql may execute different queries based on the features of postgres, such as triggers or sequences. Whereas Shoehorn_Data_Mysql or Shoehorn_Data_Adodb may use auto-numbers.
     
    Last edited: 31 Jan 2008
  4. simon w

    simon w What's a Dremel?

    Joined:
    3 Nov 2003
    Posts:
    1,302
    Likes Received:
    0
    An abstract class can contain concrete methods. For DB abstraction layers it's common to have a abstract base class (Shoehorn_Data) which implements a factory method for returning Shoehorn_Data_Pgsql, Shoehorn_Data_Mysql, etc objects. If you were you use an interface instead then all references into your DB layer have to contain the Shoehorn_Data_Pgsql, Shoehorn_Data_Mysql, etc class making a switch from one to another mure more painful.
     

Share This Page