Models
Overview
Each module in Sugar is extending the Sugar Model. This model is determined by the SugarBean, which contains methods to create, read/retrieve, update, and delete records in the database and any subclass of the SugarBean. Many of the common Sugar modules also use the SugarObjects class, which is explained in the next section.
SugarObject Templates
Sugar objects extend the concept of subclassing a step further and allow you to subclass the vardefs. This includes inheriting of fields, relationships, indexes, and language files. However, unlike subclassing, you are not limited to a single inheritance. For example, if there were a Sugar object for fields used in every module (e.g. id, deleted, or date_modified), you could have the module inherit from both the Basic Sugar object and the Person Sugar object.
To further illustrate this, let's say the Basic object type has a field 'name' with length 10 and the Company object has a field 'name' with length 20. If you inherit from Basic first and then Company, your field will inherit the Company object's length of 20. However, the module-level setting always overrides any values provided by Sugar objects, so, if the field 'name' in your module has been set to length 60, then the field's length will ultimately be 60.
There are six types of SugarObject templates:
- Basic : Contains the basic fields required by all Sugar modules
- Person : Based on the Contacts, Prospects, and Leads modules
- Issue : Based on the Bugs and Cases modules
- Company : Based on the Accounts module
- File : Based on the Documents module
- Sale : Based on the Opportunities module
SugarObject Interfaces
In addition to the object templates above, "assignable" object templates can be used for modules with records that should contain an Assigned To field. Although every module does not use this, most modules allow assignment of records to users. SugarObject interfaces allow us to add the assignable attribute to these modules.
SugarObject interfaces and SugarObject templates are very similar to one another, but the main distinction is that templates have a base class you can subclass while interfaces do not. If you look into the file structure, templates include many additional files, including a full metadata directory. This is used primarily for Module Builder.
File Structure
- ./include/SugarObjects/interfaces
- ./include/SugarObjects/templates
Implementation
There are two things you need to do to take advantage of Sugar objects:
- Subclass the SugarObject class you wish to extend for your class:
class MyClass extends Person { function MyClass() { parent::Person(); } }
- Add the following line to the end of the
vardefs.php
file:
This snippet tells the VardefManager to create a cache of the MyClass vardefs with the addition of all the default fields, assignable fields, team security fields, and all fields from the person class.VardefManager::createVardef('MyClass', 'MyClass', array('default', 'assignable', 'team_security', 'person'));
Performance Considerations
VardefManager caches the generated vardefs into a single file that is loaded at runtime. If that file is not found, Sugar loads the vardefs.php file, located in your module's directory. The same is true for language files. This caching also includes data for custom fields and any vardef or language extensions that are dropped into the extension framework.
Cache Files
- ./cache/modules/<module>/<object_name>vardefs.php
- ./cache/modules/<module>/languages/en_us.lang.php