This is the first of a three-part series devoted to the MVC framework in SugarCRM. In this particular article I will focus on the Controller.
As many of you know, MVC stands for Model-View-Controller and is a common design pattern to separate application logic from user interface logic while giving the developer easier control over the entire application. In version 5.0, the Sugar team implemented our own version of MVC which gives us the following:
- cleaner and shorter code
- one place for making application-wide changes
- ability to use a metadata driven UI
- developer flexibility to define their own logic
As you already know a typical SugarCRM URL would be something like:
index.php?module=Leads&action=DetailView&record=12345
If we break this URL down, it would tell us to load the Leads module, perform the DetailView action within the Leads module, and load the record with id = 12345. Out-of-the-box, SugarCRM ships with a default controller named aptly enough: ‘SugarController’ in /include/MVC/Controller/SugarController.php.
SugarController needs to account for using the new application framework while also supporting the old way of doing things (pre-5.0). As we said above, the action is DetailView. If the SugarController finds a file named: DetailView.php in the Leads module, it will load this file, otherwise it will check if the controller has a method named: action_detailview() which will then handle the request. There are several more configuration options which allow us to map actions directly to views or even map actions directly to files, but I will leave those until later.
This is all well and good, but what about when the developer wants to implement their own action_detailview()? In order to do this, the developer can simply drop a custom controller.php file into custom/modules/Leads.
For the SugarCRM MVC framework, we tried to stick with the mantra of convention over configuration as much as possible while also making things as dead simple as we can. Although this can lead to some upfront learning, down the road it will save time as you do not have to create complex configuration files to perform a simple task. By that token, the developer’s custom controller would be named controller.php and the class name would be: LeadsController, basically ucfirst(module).’Controller’.
Example:
class LeadsController extends SugarController{
function action_detailview(){
//your logic here.
}
}
What this allows then is for the developer to override the methods they want to and allow the SugarController to handle the other methods.
One addition thing to note here is the concept of pre_, and post_ methods.
For each action defined in the controller, there exists the possibility of pre_<action> and post_<action>. So for example a Save action could have:
pre_save(), action_save(), and post_save() each of which can be overridden in the controller.php file. Having these methods gives finer control over to the developer. With our Save example, the bean can be populated from the POST in the pre_save() method within SugarController.php, but the developer could decide then to just override the action_save(), or post_save() without having to repeat the same logic for saving POST variables to the bean object.
For more details, see the User Interface Framework section in the Sugar Developer Guide.