Skip navigation
All Places > Developer > Blog > 2015 > April
2015
Matt Marum

UnCon 2015 was a success!

Posted by Matt Marum Employee Apr 28, 2015
Thanks again to everyone who was at SugarCon UnCon!  I think we really took our UnCon to a whole new level this year and I was very happy to see it happen!  It was really satisfying to see everybody wearing their UnCon hoodies at the SugarCon after parties too.  :-)
Matt, I wasn't able to attend all the sessions!  Where can I get at the slides?

 

I got that question all the time at UnCon.  Don't worry guys!  We've got this.

 

I'm working on collecting the slides, source code, notes and any other materials produced for UnCon by the Sugar Engineering team and the Sugar Developer community.

 

Once I've got all the materials together and it's ready to share, you guys will be the first to know!  Stay tuned.

Matt Marum

UnCon 2015 Update!

Posted by Matt Marum Employee Apr 22, 2015
We had a great first day at SugarCon UnCon!

 

Initial feedback has been very positive.  Lots of great discussions between Sugar Engineers, Sugar Partners, and Sugar Customers.

 

Today is the 2nd day of UnCon and it has a packed schedule!  http://bit.ly/uncon2015agendaCome down to Plaza B today to learn more about Sugar 6 to 7 Migration, SugarCRM Mobile SDK, Sugar Logic, Shadow, and Process Author!

 

See below for some candid snapshots from yesterday's UnCon.

 



 



 



 



Sugar Developers!

 

Want to get a head start on your SugarCon UnCon experience?

 

The UnCon roundtable schedule and Github repository are now live!

 

The UnCon roundtable schedule is currently preliminary.  The final schedule gets set by the audience at the start of UnCon.  However, this document will be edited to become the master schedule for roundtable discussions at UnCon, so go ahead and bookmark it!

 

The UnCon Github repository contains all the resources that Sugar Engineering has put together for our hackathon.  We'll still be adding things up until the last minute but now is a good time to get a head start on setting up your development environment or checking out some projects.

 

See you guys in Plaza B!

For Sugar 7.7 and later versions, you can access metadata from within the Sidecar clients using 
SUGAR.App.metadata.get()

 

Many Sugar Developers are looking to build intelligent API integrations with Sugar that goes beyond Create-Read-Update-Delete (CRUD) operations.  The key to building robust and intelligent API integrations with Sugar is held within the Sugar Metadata.

 

Sometime it is interesting to understand what dependent dropdowns exist on any given Sugar module.  A common use case would be to display appropriate UI with properly populated drop down lists to end users of an integration with Sugar 7.

 



 

If you don't have the dependent dropdown formula then you are stuck guessing at what options are available or showing the user the full list of options when only a subset of them are valid choices.  The key for addressing these user experience concerns and for anybody else wanting to take their Sugar API integration to the next level is the Sugar Metadata API.

 

If you are familiar with Sugar 7 then you probably know that we use the v10 REST API to drive the Sidecar framework used in our web, mobile, and portal clients.  Sugar Logic formulas are configured in Sugar Metadata which means the Metadata API is how the Sidecar framework is made aware of them.

 



 

If you are building a Sidecar client then Sugar Logic gets handled for you automatically - but otherwise you can mine the metadata to find the tools you need.

 

For convenience, you can browse the entire Sugar metadata cache for any user using your browser's dev tools (such as Chrome Dev Tools used in example below).  Just log into Sugar 7 as your target user, open your javascript console, and run the commands below.  This will return the current metadata payload that was retrieved from server via Metadata API.

SUGAR.App.metadata._dev_data; // replace _dev_data with get() in Sugar 7.7 and later

 

In this example, the full options list of display values used is available within app_list_strings.car_list.

SUGAR.App.metadata._dev_data.app_list_strings.car_list;

 

This can be compared with the dependent dropdown formula found in the Opportunity Record view metadata.  Sugar Logic defines dependencies between fields that affects their presentation to end users.  So you'll find this information mixed into the View metadata in the dependencies hash.

SUGAR.App.metadata._dev_data.modules.Opportunities.views.record.meta.dependencies;

 



 

This should give them all the information they need to intelligently work with this dependent dropdown field.  Now they can decide how they want to handle these in their integration.

A quick note about programming against Metadata API

 

The Sugar metadata payload is pretty large so you'll want to cache it as much as possible.  It's a good idea to only retrieve the metadata for modules you care about to limit the size of the request.  You should track the metadata hash value which can be used to reload metadata only when it changes.  Again, if your code is running within Sugar 7 (and therefore using the Sidecar framework) then metadata is refreshed automatically as needed - so you can always assume the metadata you find there is up to date.

Matt Marum

Hackathon at UnCon 2015

Posted by Matt Marum Employee Apr 16, 2015
So what does Sugar Engineering have planned for the Hackathon?

The Hackathon will be informal and will run at the same time as the Roundtables in a separate part of the UnCon space.  The Hackathon space will be a lounge atmosphere with couches, beverages, food, etc.  People can work on whatever they want to but we’ll have planned projects lined up and a crowd of Sugar Engineers ready and willing to help out with anything you're working on.  Whether that's helping you get a local Sugar development environment setup, help you troubleshoot some problems, or design a fancy CRM implementation or integration with another application.

The only prize for Sugar Developers at the Hackathon is knowledge (meaning there will be no "winner").  But if a Sugar Developer creates a project or prototype and stands up and presents it at the end of UnCon then they’ll also get a coveted SugarCRM UnCon hoodie.

 



However, we've done some homework and prepared some projects that you can work.  We're in the process of creating a public GitHub repository with the UnCon materials included.  So it's a good idea to create a GitHub account if you haven't yet already.

 

Internet of Things

In an effort to try something outside the realm of “traditional” CRM and to make things a bit fun, one of the Hackathon projects I’ve planned is to explore Internet of Things solutions to CRM problems with Sugar 7 at the center.  We’ve got some prototyping gear (arduinos, raspberry pis, sensors, leds, LCDs, motors, etc) for use with designs.  We’re using Cylon.js and a Sugar API wrapper for Node.js which will allow Sugar Developers to work entirely in JavaScript to quickly build prototype IoT integrations that connect to Sugar.  This is also a fun way to learn the Sugar 7 REST API.  We're putting together a few examples that should get folks up and running a manner of minutes, even if you've never worked with microcontrollers or any other hardware before.

Sidecar Chrome Dev Tools plug-in

This is a project that a few Sugar Engineers have been working on off and on for a couple months.  This tool allows a Sugar Developer to pull up a Sugar 7 specific debug tools that allow you to visually inspect all the different Views and Layouts in the current Sugar 7 window.  We think this would be a very useful tool for Sugar Developers, whether they are new or experienced.

Dashlets

Building Dashlets is a great way to customize Sugar quickly or to integrate the Sugar user interface with a 3rd party system.  It’s a great “newbie” project for any of you new folks and we'll have a team of Sugar Engineers standing by to help.

AND MORE!

See you at SugarCon!  There's still time to register!

Matt Marum

Roundtables at UnCon 2015

Posted by Matt Marum Employee Apr 13, 2015
I want to let Sugar Developers know that we're really excited about the new format for UnCon this year!

 

Part of the new format this year is to have the UnCon venue separated into two sections.  When you first enter the space, we will have a lounge atmosphere with couches and refreshments.  This first section will be the Hackathon space and will be a topic of a later blog post.  The second half of the space furthest from the door will be where we will have (for the first time) Sugar Engineering hosted un-conference roundtable discussions and workshops.

 

So what the heck does that mean anyway?

 

Within the first hour of UnCon - You (our beloved Sugar Developer audience) will establish the topics and agenda for the roundtable section for the rest of UnCon.  Each audience approved topic gets assigned one of six roundtables, a time slot, and a moderator who is responsible for driving the discussion/workshop as they see fit.

 

This doesn't mean Sugar Engineering hasn't been doing their homework.  We've already got nearly a full schedule's worth of topics and moderators lined up to give you the goods.  These potential topics were selected based upon our discussions internally, feedback from our Sugar Partners, and from the UnCon Developer Survey.  In fact, we've already got some Sugar Developer community members lined up to help out on some specific topics.  Thanks Jeff, JustinJason, and Chad!Prepared Entry level topics

  • Sugar 7 Architecture
  • Building a Dashlet in Sugar 7
  • Debugging Sugar 7 (PHP and Javascript)
  • Sugar 7 Styleguide
  • Ask the Experts Panel
Prepared Intermediate topics
  • All about Elasticsearch
  • DevOps, Jenkins, and Vagrant stacks
  • Defining tooling for Sugar Developers
  • Implementing Customer Requirements in Sugar
  • Creating schedulers that are OnDemand friendly
  • Best practices using New Relic to monitor Sugar
  • Creating an Install Wizard for your Sugar package
Prepared Advanced topics
  • Elasticsearch Sugar internals (including customization)
  • Customizing Sugar visibility model / Sugar ACLs
  • Record View Refactor workshop
  • Sugar 6 to 7 Migration
  • Sugar Package Best Practices & Guidelines
  • Sugar 7 Load Testing & Sizing
  • SugarCRM Mobile SDK definition

 

Any or all of these topics and any others are fair game for UnCon!  We also plan on capturing notes and collateral from each topic discussed at UnCon.  This will allow us to share a bit of the experience with some of those Sugar Developers who missed a discussion because they were somewhere else at UnCon or SugarCon or were not able to make to San Francisco this year.

 

I think we've got a plan this year where everybody who comes to UnCon will be able to get what they needed!

Hey Sugar 7 Developers!

 

I wanted to make sure the community is aware of our planned refactor of the Sugar 7 Record view in Sugar 7.8.  The main point of the refactor is to move the Record view header pane out of the scrollable DIV that it is inside today.

 

Open up your browser's developer tools and inspect the the HTML of a Sugar 7 Record view.  Notice that .headerpane DIV element that contains the header is actually inside the left-hand side .main-pane DIV?  This main pane can scroll up and down and contains the record view and subpanels.

 



 

However!  If you scroll the Record view, the header pane does not move at all.  This is because we use some CSS trickery to stick it to top of the page under the Sugar 7 application main menu.  Unfortunately this has not worked consistently on all browsers and there has been a variety of bugs.

 

The plan is to refactor the current implementation of Record view away from being one monolithic Sidecar view into multiple Sidecar views that will read view metadata from a single location (using the same record.php we use today).  Ultimately we'll be able to improve the architecture of the page, fix some bugs, as well as make parts of the current Record view (such as the header pane) easier to customize.  All good stuff.

 

Since the Record view is often customized already, we plan to limit the impact on those customizations as much as possible.  For example, record view metadata customizations will be unaffected.  We will also not change the existing Record view controller, instead deprecating it and creating entirely new views and layouts.  But Sugar Engineering needs to make sure we understand all of your Record view customization use cases so that we can be prepared to make you prepared for these changes.

 

I've collected some of the common Record view customization use cases that I know about below.

  1. Adding custom field validation (such as validation tasks) to Record view (Example from Sugar Developer Guide)
  2. Adding buttons to Record view including overriding view controller to implement a custom action (Example from Sugar Developer Guide)
  3. Adding event listeners to Record context or layout (Example from Sugar Developer Guide)
  4. Adding metadata customizations such as new custom fields, panels, or Sugar Logic dependencies (Via Studio, Extensions framework, or custom directory)
  5. Adding custom views to Record layout (Example from Sugar Developer Blog)

 

Are we missing your use case?  Please post your thoughts into this Sugar Community thread or send them to developers@sugarcrm.com.  We will also have Sugar Engineers on hand to discuss this topic at UnCon at SugarCon.

Post originally written by Joo Lee.

 

Sugar 7 allows you to define your own view metadata for creating new custom layouts and views.  In these custom view definitions, the correct use of the type and name attributes is essential when you want to reuse metadata, controllers, or templates from other Sidecar components. But what are type and name?  How are they used? In this post, we hope to provide you a better understanding of these attributes and how they are used by Sidecar when your components get created.  Most importantly, this post will serve as a guide for the correct use of type and name in your Sugar 7 view metadata that will maximize your ability to reuse.

 

Read more below!

 

Review of Basic Components

 

There are three basic Sidecar components in Sugar 7 user interfaces: layout, view, and field. A layout contains views and other layouts. It is primarily used to lay out various components of a page. For a simple application, a layout should be lightweight. It should create and define other components and nothing else. A view is where most of the work happens. It is also where fields are created and are defined.

 

Components consist of three parts: definition, controller, and templates. Component definition specifies the components to be created and its customizable attributes. Controller adds behavior and logic to components via JavaScript. Templates provide HTML to the component through Handlebars template engine.

 

For more information, you can read about layouts, views, and fields in the Sugar 7.5 Developer Guide.

 

Component Definition

 

There are two ways to create and define your components. The first is to reference an existing component definition. The second is to specify it directly in your component.

 

Layout example

 

foo.php

$viewdefs['base']['layout']['foo'] = array(
   'components' => array(
      array(
         'layout' => 'header', //reference another definition
      ),
      array(
         'layout' => array( //directly include definition
            'components' => array(
               array(
                  'view' => 'title', //reference another definition
               ),
               array(
                  'view' => 'content', //reference another definition
               ),
            ),
            'type' => 'base',
            'name' => 'my-custom-main',
         ),
      ),
   ),
   'type' => 'foo',
   'name' => 'my-custom-page'
),

In the above example, the layout definition tells the application that this is a “foo” layout and the name is “my-custom-page.” It directly defines “header” and “base” layouts. For the “header” layout, the application gets the definition from “header” layout to create its components. The “base” layout, which is defined directly, has two views “title” and “content.” These two views are referenced like the “header” layout. So, the application will retrieve these definitions from the two views to create them.

 

View example

 

foo.php

$viewdefs['base']['view']['foo'] = array(
   'buttons' => array( //directly include definition
      array(
         'type' => 'button',
         'name' => 'cancel',
      ),
      array(
         'type' => 'button',
         'name' => 'save',
      ),
   ),
),

 

In the above example, the view definition indicates that this is a "foo" view, and it has two buttons: cancel and save.  The two buttons, which are defined directly, are fields with type "button" with one named "cancel" and the other "save."

 

Component Controllers

 

Both the type and name attributes are used to determine which JavaScript controller is used for a particular component.

For all component types, when the type attribute is set then it is used to select the JavaScript controller to initialize.  For views and layouts, if type attribute does not exist then the name attribute is then used. For fields, only the type attribute is examined.

 

Layout example

 

foo.php

$viewdefs['base']['layout']['foo'] = array(
   'components' => array(),
   'type' => 'foo',
),

 

In the above example, since "foo" layout has type attribute specified, the application will use the "foo" layout JavaScript controller.

 

View example

 

foo.php

$viewdefs['base']['view']['foo'] = array(
   'buttons' => array(
      array(
         'type' => 'button',
         'name' => 'save',
      ),
   ),
   'name' => 'bar',
),

 

In the above example, "foo" view does not have type attribute. So, it will look at the name attribute to get the JavaScript controller. For the button inside "foo" view, JavaScript controller for button field is used.

 

Component Templates

 

The type and name attributes also affect which HTML templates are used.

For both layouts and views, the application uses the name attribute to select the HTML template. If that template does not exist, it uses the type attribute. For views only, the template attribute can be used to specify which template to use. For fields, the template is determined by the type attribute but also a variety of other factors such as user ACL, current action, and the name of the parent view.

 

Layout example

 

foo.php

$viewdefs['base']['layout']['foo'] = array(
   'components' => array(),
   'type' => 'foo',
   'name' => 'bar',
),

 

In the above example, "foo" layout will use "bar" template in "foo" layout. If the template does not exist, it will use "foo" template.

 

View example

 

foo.php

$viewdefs['base']['view']['foo'] = array(
   'buttons' => array(),
   'type' => 'foo',
   'name' => 'bar',
   'template' => 'detail',
),

 

In the above example, "foo" view will use "detail" template in "foo" view. If that template does not exist, "bar" template will be used. If "bar" template does not exist, it will use "foo" template.

 

Best Practices

  • For clarity, specify both type and name attributes when specifying your view definitions.
  • When referencing another view or layout in your definition, use the name attribute only.

  • For views and layouts, type and name attributes should have the same value in most cases. In cases where type and name attributes need to differ, please note that the component will use the name attribute to determine its metadata, the type attribute to determine its controller and the name attribute to determine its template.

In a recent blog post by UpCurve Cloud, an Elite SugarCRM Partner, Christian Wettre showed off a cool enhancement to the Sugar 7 Saved Report Chart dashlet.  Very conveniently, they included a package you can download so you can easily install it and look at the code to see how it works without any fuss.  I just tried it in a Sugar 7.5.1 instance and it worked like a charm!

Since some of the most effective SugarCRM dashboard elements are charts based on reports, I find my dashboards full of those charts. These charts scream out for the ability to dig down into the underlying details. In the current release of SugarCRM 7 it is a little cumbersome to actually do this. We solved this with a code enhancement module that adds a drill down link to any Saved Report Chart dashlet. With this module installed you can click on the drill down link on any report based dashlet to open the dashlets underlying report in a new browser tab.

 

Head over to the UpCurve Cloud blog to see an instructional video and download this package for yourself!A quick aside.  In production, SugarCRM recommends deploying new custom dashlets instead of overriding the built-in dashlets.  Users will be able find your custom dashlet just as easily as built-in dashlets while allowing the built-in dashlets to get upgraded.