I feel a lot more enlightened now, especially reading Noah’s comment about extending the base Controller, that seems like a great way to go

Something I think is lacking around all these MVC frameworks is novel strategies and patterns for structuring your app. The samples are usually trivial and don’t get to any number of the moderately tough problems likely to be the first you hit in an app. I think the model and controller per table approach in many examples is particularly brainwashing.

Anyway… The danger is when you start changing a lot of behavior of a base component or replacing it entirely. In this case, the change is simple, so you would probably choose the path that feels the best — it’s not going to be hard to change gears later either way. If you do that asset setup the same on every page, you should really consider putting it in your overall base Controller, whether using MY_ or a standalone library (CI gurus, please chime in.)

However you structure it, you have a set of tools for avoiding code duplication. Here, it seems like you have commonality across a large section, where it’s likely you’d want all of it to change together. When you “pull up” this functionality via inheritance so it’s automatic, you reduce your potential maintenance costs. If there was a lot of variability, or strong likelihood of change in that behavior between controllers, a different approach might be better — inheritance could end up giving you combinations of behavior that you would have to work against.

Perhaps I could write a class that extends the controller class and place my common code in that. Would that be a step in the right direction away from like you say, scope-free helper functions? Is that what you are describing in your opening sentence?

Your post is valuable as it also helps other beginners who may be able to take your ideas on board more quickly than I can! Thanks once again.

I prefer to use object-oriented models where I can. The CI helpers coming in as unscoped methods scares me just a bit. I’d try making a new (abstract) class in a library file (maybe StaticController, ContentController, BasicController — something…) and drop it in autoload.

If that setup is truly global, I’d consider making a MY_Controller class in application/libraries that extends CI_Controller (see the user guide for extending core classes). You’d want to then change your existing controllers to extend MY_Controller, instead. This, presumably, would be eliminating other duplications, and so, would be valuable.

In the basic/static/content controller, I’d include a render() method and an index() method. The default implementation of index() would just call $this->render(). The render() method would use get_class($this) to find the name of the controller (probably lowercased), and load a conventionally named view.

To put this directly into code…


//application/libraries/MY_Controller.php
class MY_Controller extends Controller {
function __construct() {
parent::_construct();
$this->setup_assets();
}

//application/controllers/history.php
class History extends ContentController {
function index() {
//check for some history-specific permission and redirect on failure
$this->_render();
}
}


This setup should give you a clean path to customize the needs lightly (at constructor time, with a new action, or just tuning index), while remaining very “automatic”. This automatic behavior is entirely opt-in even if you extend ContentController. (Spring folks may disagree with this a bit, since it’s not quite open-closed…)

Another thought is that you could push this behavior up to MY_Controller as the base starting point for all of your controllers. Unless you do something else with index(), you’re going to load the view of the same name. I might actually like that a little better…

Very nice!