SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 41 of 41

Thread: Configuration

  1. #26
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    I agree. Just using composition for everything seems like it'd get out of hand. I mean using it for all dependencies.
    Well, not for all, obviously -- only for "has a" ones. "Is a" relations are still best handled via inheritance -- it's just that it should be careful in considering which is which.

    People often focus on implementation instead on the concept, which misleads them; I have myself often been guilty of that.

  2. #27
    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 devbanana
    kyberfabrikken, I was looking at your framework (...)
    What I'm especially interested in is, how do your controllers know what their child controllers are? It doesn't look to be hardcoded, so where does this information come from?
    The decision is made programatically. Per default, the controller simply looks up in an assoc. array (the property controller->map), but this can (and often will) be overridden. So yes, it is hardcoded into each controller.
    Have a look at the sample app in examples/blog-php for a concrete example - I know the documentation is lacking.

    Quote Originally Posted by devbanana
    I'm curious how you are implementing that registry. Do you have a compact example or some explanation of it? I'm very interested in "decoupling concrete class dependency", as well.

    I understand what you are saying about having one object and passing it around (for the database connection), but it has to be instantiated somewhere; where's that connection information coming from? Where's it being instantiated?
    If you checkout from svn, rather than just downloading the tar, you can see the implementation of registry in lib/k/registry.php.
    I set the registry up in the bootstrap of my application and then pass it in from there.
    For example, this could be in the bootstrap :
    PHP Code:
    $application = new Root();
    $application->registry->registerConstructor('database',
      
    create_function(
        
    '$className, $args, $registry',
        
    'return new PDO("sqlite:../foobar.sqlite", "root", "");'.
      )
    );
    $application->dispatch(); 
    And somewhere in your application, you do :
    PHP Code:
    $db $this->registry->get("database"); 

  3. #28
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    Well, what I was planning to do was something like:

    The front controller gets the request. It gets the first part of the requested action and through configuration knows which class that is associated with, so passes the request onto that handler.
    One way is to use the principle of "convention over configuration" touted by Ruby on Rails, but used by many others, including myself. It employs the features of dynamic languages at their best.

    In theory, it looks something like this:
    PHP Code:
    $controller $someValueExtractedFromRequest;
    $handler $anotherSimilarVariable;
    $parameters $theRestOfRequestValuesUsuallyAnArray;
    $controller = new $controller();
    return 
    $controller->$handler($parameters); 
    In practice it should involve some filters ahead, checking of values etc, but this is the skeleton.

  4. #29
    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 BerislavLopac
    Well, not for all, obviously -- only for "has a" ones. "Is a" relations are still best handled via inheritance -- it's just that it should be careful in considering which is which.

    People often focus on implementation instead on the concept, which misleads them; I have myself often been guilty of that.
    When a class utilizes class-inheritance it does two things at once - It inherits the type (the interface) and it inherits the implementation of this interface. The latter forms a very strong dependency between parent and child class, which isn't there if you separate the two types of inheritance, using interfaces (for type) and composition (for implementation).
    Sometimes class-inheritance is the right tool for the job, but very often it isn't. Per default, always try to use composition. Only if this gets very impractical to do, resolve to class-inheritance.

  5. #30
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    One way is to use the principle of "convention over configuration" touted by Ruby on Rails, but used by many others, including myself. It employs the features of dynamic languages at their best.
    One problem, which is the biggest IMO, with using pure convention to locate your controllers & view, is that it is very brittle and not as flexible as one might think at first.

    For example suppose we have a "blog" controller but decide we want to change the url from "blog/*" to "article/*". Whoops, all of the sudden the entire application is broken unless we set up a mod_rewrite rule or rewrite/rename all of our components. This of coarse is trivial, but imagine on a larger scale.

    You'd also have to manually setup & check several different possible paths, because you may have "blog/ID", "blog/category_name", "blog/edit/ID", "blog/year/month", etc... which would all require different things.

    Primarily for this reason, I prefer to have a mapping configuration that maps "url aliases" to "application paths" (with optional regex expressions), and then use convention on the application path to determine the controller & view. This way the application path never changes while the url is free to without breaking the application (just a simple mapping entry would need added or changed). And a secondary benefit of this is that you can also go in reverse and derive the url alias from the application path.

    I think it is ok to default to a certain convention, but I think you should also provide a means to circumvent the default convention. Even Rails now allows this with Routing.


    Quote Originally Posted by kyberfabrikken
    When a class utilizes class-inheritance it does two things at once - It inherits the type (the interface) and it inherits the implementation of this interface. The latter forms a very strong dependency between parent and child class, which isn't there if you separate the two types of inheritance
    It only inherits the implementation if you choose to let it. Quite obviously the child can do its own implementation if it wants to.

  6. #31
    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 dreamscape
    It only inherits the implementation if you choose to let it. Quite obviously the child can do its own implementation if it wants to.
    If you don't reuse implementation, there is absolutely no point in using class-inheritance. You'd be better off using interfaces.

  7. #32
    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
    If you don't reuse implementation, there is absolutely no point in using class-inheritance. You'd be better off using interfaces.
    Inheritance is not an all or nothing deal as you are trying to make it sound to prove some point of yours. You are correct that if a child is not reusing any of the parent at all, that there is little point to the inheritance. But quite obviously that was not what I meant

  8. #33
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Well, not for all, obviously -- only for "has a" ones. "Is a" relations are still best handled via inheritance -- it's just that it should be careful in considering which is which.
    For me usually the more difficult relation isn't determining if it is "is a" or "has a", but if it is "has a" or "uses a" (in the case that it is a "has a")

  9. #34
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:


    Probably well-known in this forum, but just thought I'd mention it to be sure:
    The "is a"-check is not enough to determine that one should use inheritance between classes.
    There's also the "100% rule", meaning that all methods from the parent class should be meaningfull and usefull in the child class.
    The Ellipse and Circle or Rectangle and Square could be obvious examples.
    Per
    Everything
    works on a PowerPoint slide

  10. #35
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BerislavLopac,

    The "has a" is obvious enough, but as nicely pointed out a few posts up, the hard part is if a class is dependent on another one, but it's more of a "uses a" relationship.

    kyberfabrikken,

    I like your registry implementation. What is Root, though? And if you need to use the registry in another class as you probably will need to, do you just pass it in the constructor?

    Quote Originally Posted by dreamscape
    One problem, which is the biggest IMO, with using pure convention to locate your controllers & view, is that it is very brittle and not as flexible as
    one might think at first. For example suppose we have a "blog" controller but decide we want to change the url from "blog/*" to "article/*". Whoops, all
    of the sudden the entire application is broken unless we set up a mod_rewrite rule or rewrite/rename all of our components. This of coarse is trivial,
    but imagine on a larger scale. You'd also have to manually setup & check several different possible paths, because you may have "blog/ID", "blog/category_name",
    "blog/edit/ID", "blog/year/month", etc... which would all require different things. Primarily for this reason, I prefer to have a mapping configuration
    that maps "url aliases" to "application paths" (with optional regex expressions), and then use convention on the application path to determine the controller
    & view. This way the application path never changes while the url is free to without breaking the application (just a simple mapping entry would need
    added or changed). And a secondary benefit of this is that you can also go in reverse and derive the url alias from the application path. I think it is
    ok to default to a certain convention, but I think you should also provide a means to circumvent the default convention. Even Rails now allows this with
    Routing.
    That's a good point. Would you recommend using configuration, and in what form?
    Laudetur Iesus Christus!
    Christ's Little Flock
    Jesus is the Good Shepherd

  11. #36
    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 devbanana
    I like your registry implementation. What is Root, though? And if you need to use the registry in another class as you probably will need to, do you just pass it in the constructor?
    Root is analogous to a frontcontroller, except konstrukt uses a hierarchical mvc design, rather than a rules-based dispatcher. Root is the first controller to execute. It will dispatch to another controller, which in turn may dispatch to another controller. At some point, one of the controllers won't dispatch, but will handle the request.
    I pass the registry in the constructor for each controller. (Well - in reality it's a bit more complicated than just that, but in theory).
    I happily pass the registry to lower layer components (such as model). For example, a tablegateway could use the registry to create tablerecord components, or to get to other tablegateways.

  12. #37
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    kyberfabrikken,

    Thanks for the explanation. I have been looking around your framework, as well as the blog example, and am starting to piece it together.

    You basically have a root handler, which specifies the child handlers it can "forward" to, and the default handler; and it goes the same way down the chain? I like how you have methods for specific HTTP request methods, like get, post, put, delete, and head.

    I also like how much the framework is concerned with the response headers; it is the first framework I've seen that in. And I'm glad, because mine will be doing similarly.

    I'm thinking, what about a registry that implements ArrayAccess, so you can do something like this:

    PHP Code:
    $application->registry['database'] = new PDO('dsn''user''pass'); 
    One last thing: I notice you have several public properties. I thought generally it was thought to be best to make properties private and make outside code access them via accessors so that you have control over what can be done? E.G., if you want a property to be read-only (only have a getter), or if you want to validate input, etc.
    Laudetur Iesus Christus!
    Christ's Little Flock
    Jesus is the Good Shepherd

  13. #38
    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 devbanana
    You basically have a root handler, which specifies the child handlers it can "forward" to, and the default handler; and it goes the same way down the chain?
    Exactly. And each can use whatever rules it will, to interpret the uri-fragment, relative to it's position. That way, different url's can end up being handled by the same controller. The same controller can also be moved around in different contexts.

    Quote Originally Posted by devbanana
    I'm thinking, what about a registry that implements ArrayAccess, so you can do something like this:

    PHP Code:
    $application->registry['database'] = new PDO('dsn''user''pass'); 
    Probably a good addition. I already implement __get, so you can do :
    PHP Code:
    $application->registry->database
    Or :
    PHP Code:
    $application->registry->get('database'); 
    There isn't a __set method, since you would do that by registering a constructor instead. Eg. :
    PHP Code:
    $application->registry->registerConstructor('database',
        
    create_function(''"return new PDO('dsn', 'user', 'pass');")
    ); 
    It has the benefit, that the object isn't created until it's actually needed. If that never happens, creation would be waste of precious clockcycles.

    Quote Originally Posted by devbanana
    One last thing: I notice you have several public properties. I thought generally it was thought to be best to make properties private and make outside code access them via accessors so that you have control over what can be done? E.G., if you want a property to be read-only (only have a getter), or if you want to validate input, etc.
    You're right. In some of the cases, protected would be more appropriate, but in most cases it's deliberate. The relationship between outer and inner controller is often very intimate, so it often makes sense to access data on the outer controller. I leave it as the programmers responsibility to keep controllers as independent as needed.

  14. #39
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Great, thanks for the reply. Yeah, I hadn't thought about delayed instantiation of the objects in the registry; that's interesting. How do you call them, then?
    Laudetur Iesus Christus!
    Christ's Little Flock
    Jesus is the Good Shepherd

  15. #40
    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 devbanana
    Great, thanks for the reply. Yeah, I hadn't thought about delayed instantiation of the objects in the registry; that's interesting. How do you call them, then?
    I not sure what you're asking ? The registry is in fact a combined registry + factory. If you request an object that has already been created, it is simply returned. But if you request an object, that hasn't been created, it is created by the constructor, assigned to it. Have a look at the testcase under tests/cases/registry.test.php, the 4 last tests.

  16. #41
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well you did a pretty good job at responding to me if you didn't know what I was asking. Thanks for the explanation.
    Laudetur Iesus Christus!
    Christ's Little Flock
    Jesus is the Good Shepherd


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
  •