Archives For View

This article is aimed at beginning to intermediate SugarCRM developers who want to customize views in SugarCRM version 7.

This does not go into detail about all the ins and out of creating custom views, changing metadata and handlebars, etc.  This article merely points out a single technique for extending the JavaScript for an out of the box view to a custom view.  This technique also applies to layouts, but this article will concentrate on views.

This article assumes some knowledge of JavaScript and PHP.

Creating a Custom View From an Out of the Box View

When you create a custom view in SugarCRM 7 you create a subdirectory under

{SugarCRM base dir}/custom/clients/base/views/{new view name}


{SugarCRM base dir}/custom/modules/{module name}/clients/base/views/{new view name}

with the various files within it named for the view name.  An out of the box view is one you can find under

{SugarCRM base dir}/clients/base/views/

If you wanted to override one of these out of the box views you would simply create a custom view with the same name.  You can tweak the functionality of an out of the box view by simply copying its source files to your custom view and then customizing them from there.  Let’s say, for example, that you wanted to alter the behavior of the “record” view for a given module.  You can simply copy the out of the box record view locally

cd {SugarCRM base dir}
cp -r clients/base/views/record custom/modules/{module name}/clients/base/views/record

You’ll then need to alter the metadata file (in this case record.php) to reflect the new location

$module_name = "my_ModuleName";
$viewdefs[$module_name]['base']['view']['record'] = array(
    'buttons' => array(
        'type' => 'button',
        'name' => 'cancel_button',
        'label' => 'LBL_CANCEL_BUTTON_LABEL',
        'css_class' => 'btn-invisible btn-link',

If your customizations involve JavaScript changes you’ll want to use the un-minified version of the JavaScript file to work against.  You can copy it from the jssource directory.  In this case you’d run the following command:

cp jssource/src_files/clients/base/views/record/record.js custom/modules/{module name}/clients/base/views/record

At this point you can change the various local files to your heart’s content, and anytime the “record” view is used within your module, your custom view will be used instead.

Like all changes to views and layouts, you’ll need to do a Repair and Rebuild before you see your changes take effect.  When you change the JavaScript file you’ll also need to clear your browser cache.

The Problem With Overriding An Out of the Box View

That’s wonderful until you upgrade.  The problem is that when you upgrade, the out of the box record view might receive changes but your local version of the “record” view won’t.  Over time your custom view will become more and more out of step with the out of the box view.  It could even result in your view breaking eventually.  This isn’t much of a problem for the metadata file since that’s not likely to change much from version to version.  The JavaScript file, however, can change a lot.  It would be nice if there were a way to get the benefit of the improved JavaScript while still keeping a customized version of the view.

Happily this is possible by extending the JavaScript file rather than completely overriding it.

To extend the JavaScript file you simply use JavaScript’s “extendsFrom” functionality.  In our example, to extend the record view the record.js file would look something like this:


extendsFrom: 'RecordView',

initialize: function(options) {
    console.log("We are using my customized record view, Yay!");
    this._super('initialize', [options]);


This JavaScript file will work exactly like the original except that it will now write a message to the JavaScript console whenever the view is used.

The tricky part of this is figuring out what to put in the “extendsFrom” part.  The name follows the form {Module}{Layout|View}.  If you’re extending the JavaScript for a view the {Layout|View} part will, of course, be “View”.  For the {Module} part you take the name of the view and capitalize it.  If the name has dashes in it, remove the dashes and uppercase the following word.  For example, if you were extending the JavaScript for the “filter-module-dropdown” view, the module part would turn into “FilterModuleDropdown” and the entire class to extend would become “FilterModuleDropdownView”.

If you’re ever unsure about what the class may be for the view or layout you’re extending, you can run one of the following commands in the JavaScript console and look at the results.  They should contain the names of all the view and layout classes recognized by the application:


Calling the “_super” method within an overridden method is important to get the functionality of the parent method.  You can leave it out, but then your local method must do everything the parent method did.

This technique also works if you create a custom view of a different name based on an out of the box view.  There’s no rule saying that what follows “extendsFrom” must match the name of the local view.  It’s merely the JavaScript class you’re inheriting from.

Since you inherit from the parent JavaScript class rather than completely overriding it, and use the _super() method within overridden methods, when you update you’ll automatically get the improved functionality of the base class.

A Quick Caveat

When you extend the JavaScript for a view in this manner there’s always the risk that the changes made in a given update will clash with the customizations you’ve made in your local view.  It depends on the nature of the customizations you choose to make.  There’s no good way to completely guard against that other than never touching the Javascript at all.  Extending a view this way does minimize this risk because you override only what you must rather than the entire JavaScript file.  You should, however, remain aware of the customizations you make and test them thoroughly when you update before going live.

Hello everyone, i guess for most of us is another day at work Today i want to share with you all, how you can create a custom view for any of your modules. You can use this view to integrate some script or anything inside sugar and it will look like it comes from there.

Continue Reading...

Hey all, how many times have you made some php/html/smarty template files and been wondering how to get SugarCRM CSS and JS in it. Well here is the solution for you:   <?php /** * @author Milos Miric aka eitrix @ * */ $themeObject = SugarThemeRegistry::current(); // get css $css = $themeObject->getCSS(); // get

Continue Reading...

Hello everyone Hope you had a great time for new year and all other holidays. It’s been a while since i wrote last time because i was busy myself working on some projects and having some good times on mountain. I don’t know to ski although i do enjoy snow much. Maybe i learn one day who

Continue Reading...

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:


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’.


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.