It seems that this setting does not regard the entire document in principle, but selected text. Hence if you have a document which for example, for what ever reason unknown or otherwise, was originated in US English, setting the language to UK English will only last while you are working on that sentence (where the cursor was upon changing the setting), and not the entire document.

As someone else said on this blog - the language setting is actually in the text (now XML structured in Word 2007), and not in the document header. Presumably this is so that you can write a document consisting of text in multiple languages, whilst avoiding Word penalising you for incorrect English within your French text for example.

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!

But on the subject of “color” vs “colour” - I found this list! I have been at this desk too long.