In this thread, I would refer this as The SECOND Method to Modularing Application:
ForumModule.php the module class file
components/ containing reusable user components
views/ containing view files for widgets
controllers/ containing controller class files
DefaultController.php the default controller class file
extensions/ containing third-party extensions
models/ containing model class files
views/ containing controller view and layout files
layouts/ containing layout view files
default/ containing view files for DefaultController
index.php the index view file
My questions are:
Which method to follow ?
What's in ForumModule.php and what do you usually code there actually ?
May I rename the DefaultController.php to something else ? And which config will then effecting it ?
So, when I use the second modular fashion way, how do I access them from the url ?
I would like to manage my web apps like this structure for example:
controllers/ //--> BIG QUESTION IS WILL I STILL NEED A CONTROLLERS FOLDEER OUT HERE WHEN I USE THIS MODULAR FASHION ?
Sorry for lots of questions but as I read through the docs I got myself frustrated, and I know I will not be able to solve this alone…So, please kindly help.
Good question. I think I should find some time to write a cookbook page on this topic.
The main difference between these two methods is that in the first method, controller views are still under the same base view path and components/models are shared by all controllers. In the second method, each module has its own base view path, components and models, and is thus more self-contained.
If you intend to reuse a set of controllers together with their dependent code (e.g. views, models), you should consider using modules. If you have several teams, each working on a big feature, you may also consider using modules to organize these features. For smaller projects and teams, the first method is simpler.
ForumModule.php may be considered the sub-application instance for the module. We often need to override its init() method to initialize properties of the module instance, like we do with the application using app config.
Yes. You can set the 'defaultController' property of the module in its init() method.
You can access a controller under a module using URL: index.php?r=moduleID/controllerID/actionID. For URL index.php?r=moduleID, the default controller's default action will be invoked.
You can still have a 'controllers' directory for the parent application (actually, you often need to). Controllers under that directory are accessed as usual, using URL: index.php?r=controllerID/actionID
The first method is more suitable for a small to medium sized project developed and maintained by one or several developers. It is mainly about organizing controllers in directories. Controllers are sharing most code (e.g. components, models).
The second method is better for big projects developed by several teams. Each module is relatively self-contained and is developed by a single team. Components and models under a module directory are mainly used by the module alone.
Where do I have to put my filters then ? Should I store the filters within another folder ?
Do this modular fashion application structure effects application performance ?
And, on UserModule.php, I still do not know what to do, which methods should be overriden ? Please see the code below:
class UserModule extends CWebModule
public function __construct()
public function init()
Am I able to put a "config" folder in my "usermodule" folder as I am trying to keep the config for each module in a modular fashion too, and don't want nothing to do with the main application configuration?
Do you mean action filters? Are they written in classes? If so, you can store them under protected/components, or <moduleID>/components (assuming the filters are only used by <moduleID>).
The performance degradation is very small. For each request for a controller under a module, it will need additional cost of two file operations. For non-module controllers, there's no performance degradation.
You mainly need to override init() method. Don't touch __construct().
In the init() method, you can call configure($configFile) to initialize the module like you do with application. Here $configFile refers to a module config file (similar to an app config).
If you want to reuse the module, you should put language files under <moduleID>/messages. You also need to configure a new message source in the init() method of the module so that it can use the module messages.