, ,

One of the features of Kohana that I didn’t grasp straight away was its cascading filesystem. Which in short allows you to “override” files lower down in the hierarchy with your own version. For the full run down have a look at explanation on Kohan’s documentaion . Why is it useful? Well for a start it helps keep your grubby mitts off of external module code when you want to customise them and keeps all your application specific changes in one place.

So for example imagine you download a module to help manage users on your site. You can drop it in your modules folder, activate it and the world is good(ish). Even with all your CSS wizardry you can’t get the default views to look the way you want on the page. So you take a look at the relevant view in the module and see some changes you’d like to make. But if you go and change the module’s files directly you end up making it specific to your application which means it’s tough to use in another application or keep up to date if the author releases a new version.

But with the cascading filesystem you can just take a copy of the relevant view file in the modules folder and put it in a matching folder within your applications folder (which is higher in priority), modify it and then when your application is run, Kohana will use your altered file and not the modules default one. The cascading filesystem also means you can keep all of your application specific configuration files in one place within your application so you don’t risk overwriting them when the module changes.

You can search the filesystem yourself with the Kohana::find_file method.

I think it’s a really useful feature especially when you’re dealing with 3rd party modules, or want to make some of your code more transportable. Check out the diagram for the hierarchy and what overrides what.