Thursday, April 24, 2014

Let Us Continue...

Last week we took a peek under the hood of Sugar 7 to learn about the location of some of its un-minified JavaScript code. Today, we will continue that discussion, except we will focus on core components of the Sidecar technology that makes up the new MVC client in Sugar 7.

Before we proceed, it is worth noting that Sidecar is a combination of open source JavaScript libraries, including jQuery, Backbone and Underscore, among others. Thus, when we talk about Sidecar, what we are really talking about is the consolidated result of these technologies. 

Bearing that in mind, the article referenced at the top of this post speaks to code relating to customizations that we can apply to change a portion of the MVC client. Another portion of that same client adds some magic behind the scenes to tie together the actions occurring on the interface with the backend.

Although we would not be modifying this code, it is worth studying it as it provides us some really good insights into the manner in which the Sidecar technology implements the Sugar object model and framework. But as with the previous post, this task is far easier to accomplish if we have access to the un-minified sources.

Below is a listing of files you should find helpful in your continued learning about Sugar 7 and Sidecar:

Sugar Object
Un-minified Source Folder
ACL, Controller, Metadata, User
SugarBean, Validations 
Data Formatting, Logger
Handlebars Helpers, Views, Alerts

Give those folders a look and share any gems you find within the comments.

Monday, April 14, 2014

The Issue of Legibility

Those of you that have been working with Sugar 7 have likely already noted that much of the JavaScript code utilized is minified. While that is a nifty trick to squeeze out some more performance, it makes code very difficult to read, such as the snippet inserted below:

({inlineEditMode:false,createMode:false,plugins:['SugarLogic','ErrorDecoration','GridBuilder','Editable','Audit','FindDuplicates','ToggleMoreLess'],enableHeaderButtons:true,enableHeaderPane:true,events:{'click .record-edit-link-wrapper':'handleEdit','click a[name=cancel_button]':'cancelClicked','click [data-action=scroll]':'paginateRecord','click .record-panel-header':'togglePanel','click .tab a':'setActiveTab'},buttons:null...

From the standpoint of a consultant, and one in charge of applying code level modifications to a given Sugar instance, having to unravel code like this in order to work on a customization is a bit of a nightmare. One is also put in a situation in which one has to rely on the use of JavaScript beautifiers and similar tools to display the code in a more legible manner. 

No need to worry, however. Legible versions of the JavaScript code that Sugar utilizes and in turn, minifies, are easily accessible, thus simplifying our work. The table below gives us a listing of the various file locations that might be of interest to developers:

Minified Files
Un-minified Source

In future posts we will take a closer look at other aspects of the file system that are equally important.

Have fun exploring!

Tuesday, April 1, 2014

SugarCRM Cookbook: Retrieving User Roles

One of the challenges relating to the adoption of any new technology is understanding the manner in which one accomplishes equivalent tasks based on our experience with previous versions of the same technology. Sugar 7 is no exception to this rule, and this challenge is perhaps its biggest within the development community.

With that in mind, lets talk about a recent situation I came across that very much speaks to this point. In short, in the course of talking about the 7.x technology, the question arose of how one would go about retrieving a list of Roles assigned to a given user. Because we have to do this through a JavaScript based controller, techniques we might have used in the past are no longer applicable.

For the purposes of our example we will assume that we wish to retrieve the list of Roles assigned to the currently logged in user, in turn allowing us to see some details about the manner in which we interact with the current user, also a common need and one that also differs greatly. 

The following Gist will allow us to retrieve the Roles:

NOTE: Roles are only accessible to Admin level users and as such, the above code would only function if executed by a user with Admin privileges. In turn, it would also be best to specify a particular user ID rather than relying on the current user.