Hey skunkbad, thanks for your comments. Just like CI has always been, it's still extremely flexible, and in some ways more than ever. I think a lot of that doesn't come through until you start playing with it. So a lot of what has been seen in the articles isn't on the "exciting" front that you might see in a new features brochure, but should really help in the long run.
As for DI and needing to inject the database dependency - there's no need to do that if you don't want. The way it currently stands, you can always grab an instance of the database by doing
Code:
$db = Services::database('default');
If you choose to use DI in your own libraries, then you can inject that instance when you create new objects if you want. Or you can pull another instance (or a shared instance) within the library. It's all up to you.
As for DI/versus Service Locator, that topic always brings up a lot of debate.
After all of the reading that I've done on the topic, the best description I've seen says that the only difference between a DI Container and a Service Locator is whether it's used from within the class that is using it or outside with the instance passed in. It should be noted that actual DI is completely separate from a DI container. So, the current solution, if used in the controller and the instance passed into the libraries, is acting as a DI container. If you using the current solution inside one of your objects, it's acting as a Service Locator. And the primary reason that people get up and arms about all of this is for testability.
But, yes, we use it internally as a DI container everywhere. Well, I think there's one place that I have to fix in the IncomingRequest class, but that won't be there for much longer.
Redirects: if you don't want a function to be forced to redirect, then don't call the force_https() method. Calling the method immediately does a redirect, so that would be up to your app design to correctly. There's several different ways to restrict things (globally, per-controller, or using the force_https method manually), so no worries there.
And, yes, usability is a big concern, so I definitely appreciate seeing where people are concerned about it. Things will continue to improve in those areas, and a lot of times the things you might be concerned about are shown in their most flexible state, not the easiest, because the blogs are, in part, trying to show the flexibility and power available. I'll try and keep the simplicity in mind while writing the articles, too, so that it doesn't seem like it's growing that much more difficult. Because the 3 mantras I've tried to keep in mind have been simplicity, flexibility, and speed.
