SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 41
  1. #1
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    MVC Config Controller... best way to implement?

    Hey,

    I'm wondering if anyone could add their page into my book for this. So far, I've got the problem of trying to work out which way to design the configuration

    of my application.

    So far, I'm thinking of implementing the Config class as such:

    class Config loads GLOBAL.ini via. parse_ini_file (only read access needed at this stage).

    PHP Code:
    $Config = new Config('GLOBAL.ini'); 
    GLOBAL.ini:

    Code:
    [Configuration]
    ;loader = MySQL|INI|XML 
    ; This settings tells what medium to use as configuration storage.
    loader = XML
    
    ... etc ...
    
    [Database]
    username = uid
    password = pass
    
    ... etc ...
    Class config then initiates $loader Class (e.g. MySQL, INI, XML)


    ... class.config.php ...

    PHP Code:
    public function __construct($filename)
    {
      
    $params parse_ini_file($filename);

      
    $this->loader = new $params['Configuration']['loader'];
    }

    public function 
    getVar($name)
    {
      return(
    $this->loader->getVar($name));

    PHP Code:
    $nickname $Config->getVar('IRCBot.Nickname'); 
    ... class.XML.php ...

    PHP Code:
    class XML extends BaseConfig {

    //Open config.IRCBot.xml, load vars into memory etc.

    }


    ... class.
    BaseConfig.php ...

    class 
    BaseConfig {

    //Used as a wrapper for generic functions (logging etc.)



    Benefits: Highly configurable (or so, I think).

    Drawbacks: $Config would have to be passed to each MVC controller, HTTPRequest, PageController etc.

    PHP Code:
    $Config = new Config('GLOBAL.ini');

    $RequestHandler = new HTTPRequest($Config);
    $ResponseHandler = new HTTPResponse($Config);

    $PreFilterChain = new FilterManager($RequestHandler$ResponseHandler'prefilters'$Config);
    $PreFilterChain->doFilters(); 
    as apposed to (preferred):

    PHP Code:
    $RequestHandler = new HTTPRequest();
    $ResponseHandler = new HTTPResponse();

    $PreFilterChain = new FilterManager($RequestHandler$ResponseHandler'prefilters');
    $PreFilterChain->doFilters(); 
    Is there a way that I can make it so all the new Controllers I initiate have access to the Config class, without initiating it within each Controller

    e.g.

    PHP Code:
    class HTTPRequest
    {
      private 
    $variables;
      private 
    $Config;

      function 
    __construct()
      {
        
    $this->Config = new Config('GLOBAL.ini');

        
    $this->variables = array(
          
    '_REQUEST' => $_REQUEST,
          
    '_GET'     => $_GET,
          
    '_POST'    => $_POST,
          
    '_COOKIE'  => $_COOKIE
        
    );
      } 

    Thanks for reading :P

    Any ideas/input much welcomed!


    I'm using PHP5, I've heard of Singletons, but should this be used?
    Keep life simple... don't put your head through plexiglass.

  2. #2
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also,

    What would be quite handy which I've failed to include:

    The website stores all it's vars in the MySQL database; so the GLOBAL.ini loader would be MySQL.

    However, the Contact.php controller (used to send emails to the Admin, etc) works much quicker <*insert better excuse here*>, hence stores all it's variables in an INI file, called config.Contact.ini.

    Since the GLOBAL $Config is currently set to MySQL, I'm trying to think of a flexible way, without breaking the non-hacking attitude that I've tried to follow, to carry this out.

    The only thing I can think of, would get to have a function within the GLOBAL $Config class where you can ask it to separately load another configuration file, in this case, config.Contact.ini via. INI Config Class.

    (... called within Contact.php View ...)

    PHP Code:
    $contact_settings $Config->loadChild('Contact.ini');
    $admin_emailaddress $contact_settings->getVar('EmailAddress.Admin'); 
    Any input what would be the best way to do this from their point of view, and if similar to my view, what would "loadChild()" look like in the Config class?

    Thanks!
    Keep life simple... don't put your head through plexiglass.

  3. #3
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    First of all, ini's and xml seem like a big waste of time if your just doing some simple config files.

    Just use an array and pass it around. No need to get complicated. It is pretty much just as readable.

    PHP Code:
    // config.php
    // Include this file where ever you need it.
    // Give it a unique name (no globals please)
    $__config['database'] = 'mysql';
    // etc. 
    In terms of passing the config around for the controllers you can do something like this:

    PHP Code:
    class ApplicationController{

    public 
    $config;

    public 
    __construct($config){
    $this->config config;
    }

    public 
    useController($controller){
    controller = new $controller();
    controller->config $this->config;
    }
    }
    class 
    MyController extends ApplicationController{

    Of course that style assumes a front controller style.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  4. #4
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by The New Guy View Post
    First of all, ini's and xml seem like a big waste of time if your just doing some simple config files.

    Just use an array and pass it around. No need to get complicated. It is pretty much just as readable.

    PHP Code:
    // config.php
    // Include this file where ever you need it.
    // Give it a unique name (no globals please)
    $__config['database'] = 'mysql';
    // etc. 
    In terms of passing the config around for the controllers you can do something like this:

    PHP Code:
    class ApplicationController{

    public 
    $config;

    public 
    __construct($config){
    $this->config config;
    }

    public 
    useController($controller){
    controller = new $controller();
    controller->config $this->config;
    }
    }
    class 
    MyController extends ApplicationController{

    Of course that style assumes a front controller style.
    Thanks for your reply, The New Guy.

    I wasn't trying to over simplify the example, but I also wasn't trying to punch out loads of lines of code for the explaination either.

    I completely see your valid point ref ini's/xml's for config purpose, however this is the structure I'm wanting to follow for several reasons. This doesn't mean that every hit to index.php will parse the ini file, as that is insane. I've got ideas for storage of the flatfile config that has been optimised/loaded into memory/serialised etc but that was outside the scope of my question.

    I get your idea, about setting the config var in one controller and using that as the Base. To be honest, I didn't think of that however, I may use that idea... I mull over that I think.

    In the mean time, does anyone else have any input?

    I'm still a little lost also about the best way to write that loadChild function.

    Thanks
    Keep life simple... don't put your head through plexiglass.

  5. #5
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > In the mean time, does anyone else have any input?

    Use an array for your configuration; I too used to use XML for a while, but I soon tired of it after a while, after I realised that at the end of the day I was taking the parameters from an array anyways.

    Now I just use an array, inside an INCLUDE file and that's all I need; I don't need anything heavier than this, and I can't see a given situation where I would need anything more than that.

    For greater flexibility, encapsulate that array in a class, but only because you have the support of Interfaces in PHP5, and nothing more. On the point of using a Singleton for your configuration, I wouldn't...

    Seams a bit extreme, just for your configuration and nothing else... Wasteful.

  6. #6
    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)
    "Singleton" is another name for "global variable" - stay clear of it. Passing the dependency in through the constructor is by far the better design.

    If you find that you have to pass too many objects around (Constructors taking half a dozen of objects as parameters), you can consider using a registry or a factory pattern. But don't worry too much about that until it actually becomes a problem.

    In my experience, people often instinctively have an aversion to pass objects in the constructor, because it seems like a lot of bureaucracy. In reality, it's often far less problematic, than it seems.

  7. #7
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    If you find that you have to pass too many objects around (Constructors taking half a dozen of objects as parameters)
    Half a dozen? You've waited too long then I think. IMO, more than 3 objects as parameters is a tell tale sign that you need to do some re-factoring.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  8. #8
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the replies.

    I've had a think, threw together some test cases and decided to go along with a Registry pattern.

    It'll mean hunting through the lines of code that i've put together thus far to update, but I think this will work for now and allow me to develop the other sections of the code base.
    Keep life simple... don't put your head through plexiglass.

  9. #9
    SitePoint Guru aamonkey's Avatar
    Join Date
    Sep 2004
    Location
    kansas
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    "Singleton" is another name for "global variable" - stay clear of it. Passing the dependency in through the constructor is by far the better design.

    If you find that you have to pass too many objects around (Constructors taking half a dozen of objects as parameters), you can consider using a registry or a factory pattern. But don't worry too much about that until it actually becomes a problem.
    This is something that has never made sense to me, so I'll bring it up now

    I agree that a singleton is really no different from a global...but in lieu of that people always recommend a registry, which if it's NOT a singleton, leaves you with the same problem of passing around the registry object. If it IS a singleton, then you've just given your singleton a fancier name. I'm not saying that I have a solution--I mean at some point you HAVE to use some type of globally available information. I have just read a lot of advice that says that a global is bad, a singleton is better, and a registry even better than that. But in my mind they're all the exact same thing....

  10. #10
    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 aamonkey View Post
    If [the registry] IS a singleton, then you've just given your singleton a fancier name.
    Yep. If you do that, I wouldn't even use the name registry to describe it. You have to pass the registry around for it to be a registry.

    Quote Originally Posted by aamonkey View Post
    a registry, which if it's NOT a singleton, leaves you with the same problem of passing around the registry object.
    You have reduced the problem, but not completely removed it. Instead of having to pass multiple objects around, you now only have to pass one.
    The biggest problem with multiple objects is that when you add or remove objects to the parameter-list of the constructor, you have to revisit all code, which uses the constructor. Using a registry, you get a stable interface. This makes changes a lot easier.

  11. #11
    SitePoint Guru aamonkey's Avatar
    Join Date
    Sep 2004
    Location
    kansas
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    You have reduced the problem, but not completely removed it. Instead of having to pass multiple objects around, you now only have to pass one.
    Good point.
    Quote Originally Posted by kyberfabrikken View Post
    The biggest problem with multiple objects is that when you add or remove objects to the parameter-list of the constructor, you have to revisit all code, which uses the constructor. Using a registry, you get a stable interface. This makes changes a lot easier.
    The concern I have about a registry, and why I think it's as bad as a global is that it is a dumping ground for variables and objects, which are placed there from different parts of different scripts. Yes they are encapsulated, but you can accidently overwrite a registry variable and not notice the effects of your action until some weird bug pops up down the line. IMHO this is the biggest reason why globals are considered evil.

    I suppose you could write the registry to throw an error whenever you try to overwrite a variable, but I imagine there would be times that changing a registry var/object would be desired....

  12. #12
    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 aamonkey View Post
    Yes they are encapsulated, but you can accidently overwrite a registry variable and not notice the effects of your action until some weird bug pops up down the line. IMHO this is the biggest reason why globals are considered evil.
    One way to do it is to have a hierarchy of registries. Instead of passing your own registry to a deeper object, you create a child registry from your own, which has a link back to its parent. When you assign variables to the registry, it "shadows" over any variables in the parent registry, but doesn't replace them. This mimics the way that dynamic scope works in languages like lisp, and IMHO is a very elegant solution. For most applications, it's a bit overkill though. A simple registry still give you a means to encapsulate malicious code. With global variables in play, you can't shield off code, even when you know it's misbehaving. It may not solve all problems, but at least it's a step on the road.

    Another problem with a registry is that it's a very implicit interface. There is no easy way to inspect code, and find out which dependencies it has. This is much easier if the constructor takes explicit arguments.

  13. #13
    SitePoint Guru aamonkey's Avatar
    Join Date
    Sep 2004
    Location
    kansas
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    One way to do it is to have a hierarchy of registries. Instead of passing your own registry to a deeper object, you create a child registry from your own, which has a link back to its parent. When you assign variables to the registry, it "shadows" over any variables in the parent registry, but doesn't replace them. This mimics the way that dynamic scope works in languages like lisp, and IMHO is a very elegant solution.
    It sounds very interesting, but do you know of any simple example of that type of thing? It's blowing my mind a bit...

    Quote Originally Posted by kyberfabrikken View Post
    With global variables in play, you can't shield off code, even when you know it's misbehaving. It may not solve all problems, but at least it's a step on the road.
    That's true, and you're starting to convince me that it IS the best solution available...


    Quote Originally Posted by kyberfabrikken View Post
    Another problem with a registry is that it's a very implicit interface. There is no easy way to inspect code, and find out which dependencies it has. This is much easier if the constructor takes explicit arguments.
    I think that is my main problem with registries (as much (or as little) as I understand them)...you don't really reduce any dependencies, you just make them harder to find when you're troubleshooting.

  14. #14
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How is it harder to find? You still have to make an explicit call to the Registry to get the required object.

  15. #15
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aamonkey View Post
    I think that is my main problem with registries (as much (or as little) as I understand them)...you don't really reduce any dependencies, you just make them harder to find when you're troubleshooting.
    Agreed. In fact, that's the concept i was trying to express in this post i put in application design.

    I think using a registry makes objects less transparent as unless you look into the class that uses the registry, you do not know what objects it will need from that registry. The most you can do is leave a doc block or note to say "this class requires an instance of this class x from the registry to work". This makes the objects dependancies harder to find, as the only interface argument would be a registry.

  16. #16
    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 skinny monkey View Post
    I think using a registry makes objects less transparent as unless you look into the class that uses the registry, you do not know what objects it will need from that registry. (...) This makes the objects dependancies harder to find, as the only interface argument would be a registry.
    It's true, but it's the cost to pay for using a registry. In most cases, I think it's worth it, but if the class only have few dependencies, I would prefer to put them explicitly in the constructor.

    Quote Originally Posted by shea View Post
    How is it harder to find? You still have to make an explicit call to the Registry to get the required object.
    Yes, but you need to look into the implementation of the class, rather than just it's interface (constructor).

    Quote Originally Posted by aamonkey View Post
    It sounds very interesting, but do you know of any simple example of that type of thing? It's blowing my mind a bit...
    I don't know of any simple examples in PHP.

    I think PicoContainer supports this, but it's a dependency injection container - not a registry. They solve the problem in a slightly different way. IMHO this fits better with static typed languages like Java.

    A dead simple example to illustrate my point:

    PHP Code:
    <?php
    class Registry_ClassNotRegisteredException extends Exception {}

    class 
    Registry
    {
      protected 
    $parent;
      protected 
    $instances = Array();

      function 
    __construct($parent NULL) {
        
    $this->parent $parent;
      }

      function 
    get($className) {
        if (isset(
    $this->instances[strtolower($className)])) {
          return 
    $this->instances[strtolower($className)];
        }
        if (
    $this->parent) {
          return 
    $this->parent->get($className);
        }
        throw new 
    Registry_ClassNotRegisteredException();
      }

      function 
    set($className$instance) {
        
    $this->instances[strtolower($className)] = $instance;
        return 
    $instance;
      }
    }

    // example

    function do_stuff_with_foo($registry) {
      
    $registry->get("foo")->bar 42;
    }

    function 
    test_one() {
      echo 
    "\nTest one. Using Registry as a simple container.\n";
      
    $registry = new Registry();
      
    $foo = new StdClass();
      
    $foo->bar 0;
      
    $registry->set("foo"$foo);

      echo 
    "foo->bar = ".$foo->bar."\n";
      echo 
    "calling do_stuff_with_foo\n";
      
    do_stuff_with_foo($registry);
      echo 
    "foo->bar = ".$foo->bar."\n";
    }

    function 
    test_two() {
      echo 
    "\nTest two. Creating a local registry to shield for the main registry.\n";
      
    $registry = new Registry();
      
    $foo = new StdClass();
      
    $foo->bar 0;
      
    $registry->set("foo"$foo);

      
    $local_registry = new Registry($registry);
      
    $local_foo = new StdClass();
      
    $local_foo->bar 0;
      
    $local_registry->set("foo"$local_foo);

      echo 
    "foo->bar = ".$foo->bar."\n";
      echo 
    "local_foo->bar = ".$local_foo->bar."\n";
      echo 
    "calling do_stuff_with_foo\n";
      
    do_stuff_with_foo($local_registry);

      echo 
    "local_foo->bar = ".$local_foo->bar."\n";
      echo 
    "foo->bar = ".$foo->bar."\n";
    }

    test_one();
    test_two();
    OK. Maybe not the best example in the world, but I hope you get the point.

  17. #17
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Yes, but you need to look into the implementation of the class, rather than just it's interface (constructor).
    The words from the poster was "when troubleshooting". I agree that the dependencies of the class are masked when passing in a Registry, however when troubleshooting you are going to be examining the implementation of a class regardless. So again, how does a Registry make that any harder?

  18. #18
    SitePoint Zealot
    Join Date
    Dec 2004
    Location
    virginia
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So then what makes the singleton bad design?

  19. #19
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by joflow View Post
    So then what makes the singleton bad design?
    Its a global. Though, so to is a registry object which is passed around. The only real difference is that the registry is easier test in relation to other objects.
    Last edited by The New Guy; Mar 25, 2007 at 10:40.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  20. #20
    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 The New Guy View Post
    Though, so to is a registry object passed around.
    If you pass a registry around, it's not a global.

  21. #21
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    If you pass a registry around, it's not a global.
    Strictly speaking yes. But, I like to think of it as such because it is trying to solve the same problem of dependency and even when you pass it around it can become as spread out as a natural global. Treating it as a global I tend to be less liberal with it. Since, registries are last ditch efforts no matter the implementation.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  22. #22
    SitePoint Zealot
    Join Date
    Dec 2004
    Location
    virginia
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So what are the benefits of adding a db connection object to a registry as opposed to a DB connection singleton. Would that (the registry approach) not require me to create a DB object before its actually needed in order to ensure its in the registry when it is needed? I dont understand what exactly makes the singleton worse then a registry.

  23. #23
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by joflow View Post
    I dont understand what exactly makes the singleton worse then a registry.
    The object within a Registry has been created and registered manually by the programmer. It's not too thightly coupled to the using classes and it can be identified and exchanged. The Singleton simply is as it is in your application, even where you might not need and want it. Passing the DB connection explicitely (like foo ($db)) or as element of a registry makes the application more transparent and avoids side-effects.
    Would that (the registry approach) not require me to create a DB object before its actually needed in order to ensure its in the registry when it is needed?
    When fetching an instance of your DB connection you might check if there is one in your Registry already, if not create it and put it into the Registry.

    I believe Singletons should only be used to enforce an only-one-instance-per-script policy as the name suggests, otherwise the GoF should have called it ... err ... Globalton.

  24. #24
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can't see how I missed this,

    > In reality, it's often far less problematic, than it seems.



    I used to have a serious issue with passing in through the constructor, until I moved to PHP5 for the most part (type hints helped me overcome the problem), where dependency was the issue, but it's less so now.

    But it's not the type hints alone though, it's about better design that helps to eleviate any problems. But I certainly wouldn't leave it until the parameter count reached the suggested amount of six

    Any more than three, and I'd be looking towards refactoring. Using a Registry or Factory to me isn't an ideal solution though; To me it would be better just to encapsulate the parameters in question, within a container and leave it that...

    If you feel that there is a purpose for a Factory, push the Factory towards a class method on the class in question, rather than pass the Factory via the constructor. In most cases, the Factory in question, the knowledge it has/creates is more or less, related towards the responsibility of that given class anyways, so there is little, or no need for that separation.

    This is why I have this interface for example,

    PHP Code:
    interface QFactory_Interface {
    public function 
    createMethod();

    Well, that's how I look at it anyways... The dependency of the Factory is self contained; If you pass in the Factory via the constructor, then this couples that factory instance to something else, likely in a higher layer.

  25. #25
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    You have to pass the registry around for it to be a registry.
    I completely disagree. And so does Fowler, at least in POEAA where he states he prefers to access his registry through static methods. The entire point of registries are to make objects globally accessible to the application, and a static interface is the easiest for any point of the application to find.

    But no matter what type of registry interface we prefer, I'm sure we can all agree that putting objects in a registry is a last ditch effort.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite


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
  •