| SitePoint Sponsor |
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.Originally Posted by devbanana
People often focus on implementation instead on the concept, which misleads them; I have myself often been guilty of that.
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.
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 :
And somewhere in your application, you do :PHP Code:$application = new Root();
$application->registry->registerConstructor('database',
create_function(
'$className, $args, $registry',
'return new PDO("sqlite:../foobar.sqlite", "root", "");'.
)
);
$application->dispatch();
PHP Code:$db = $this->registry->get("database");
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:
In practice it should involve some filters ahead, checking of values etc, but this is the skeleton.PHP Code:$controller = $someValueExtractedFromRequest;
$handler = $anotherSimilarVariable;
$parameters = $theRestOfRequestValuesUsuallyAnArray;
$controller = new $controller();
return $controller->$handler($parameters);
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.
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.
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.
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
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")
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
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?
That's a good point. Would you recommend using configuration, and in what form?
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.
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:
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.PHP Code:$application->registry['database'] = new PDO('dsn', 'user', 'pass');
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.
Probably a good addition. I already implement __get, so you can do :
Or :PHP Code:$application->registry->database;
There isn't a __set method, since you would do that by registering a constructor instead. Eg. :PHP Code:$application->registry->get('database');
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.PHP Code:$application->registry->registerConstructor('database',
create_function('', "return new PDO('dsn', 'user', 'pass');")
);
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.
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.
Well you did a pretty good job at responding to me if you didn't know what I was asking.Thanks for the explanation.
Posting Permissions
Bookmarks