Anatomy of an Extension
SuiteCommerce extensions generally include the following types of files. If you create a baseline extension using the default for each command-line option as described in Create a Baseline Extension, you can view examples of most of these files in your Workspace directory.
File |
Description |
Example Baseline Extension File* |
---|---|---|
Entry Point |
An essential file in any extension with JavaScript is the entry point file. When an extension is loaded into a site’s application, this is the file that is called. In the entry point JavaScript file, you should define a module. Every JavaScript-based file in an extension must be created as a module and SuiteCommerce sites use asynchronous module definition (AMD), which relies on two libraries: RequireJS and almond. Specify these things when you define a module:
|
Acme. This file resides in: Workspace/ |
Views |
Views are part of the JavaScript layer between the application and the final rendered HTML page. A view is a JavaScript file that provides instructions about how to build the HTML page (along with a template to use). Views are also useful actors in linking the UI of the site and both the JavaScript and data layers. Define views in your extension according to the version of SuiteCommerce used for your website. SuiteCommerce or SCA 2020.2 or later: You should use the SCView class instead of Backbone.View when defining views. SCView is based on Backbone.View, but also includes additional methods specific to SuiteCommerce. See Views in an Extension for more information. SCA 2020.1 or earlier: Define a view that extends Backbone.View. See Work with Views in an Extension for more information about working with views. |
MyCoolModule.View.js This file resides in: Workspace/ |
Templates |
Rather than use raw HTML pages, SuiteCommerce extensions use files with a .tpl file extension, as well as syntax provided by the Handlebars framework. Template files are processed each time they are to be rendered by a view, and can be thought of as something between an HTML and a JavaScript file. Although you should not include raw JavaScript in template files, you can use things like predefined variables and helper functions. |
acme_ This file resides in: Workspace/ |
Models |
Just as SuiteCommerce has a special class for dealing with the visual part of our Commerce website application, the view class, it also has a special class for handling data called a model. The model is a data layer and performs many functions related to data, such as synchronizing data between the client (frontend) and the server (backend). Typically, when rendering a view that includes data, you will pass it a model. For more information, see Models in an Extension. |
See the information in this table about the Frontend Model and Backend Model. |
Frontend Models |
The extension developer tools create two initial frontend models for each module in your extension, one model that works with SuiteScript 1.0 services and one that works with SuiteScript 2.0 services. For more information, see What Happens When You Create a Baseline Extension? Define views in your extension according to the version of SuiteCommerce used for your website. SuiteCommerce or SCA 2020.1 or later: Starting with SuiteCommerce release 2020.1, all frontend models use the SCModel class included in the extensibility API. The SCModel class is built on a modified version of Backbone.Model. To use it, you add it as a dependency and then extend it to include our own properties. For information about how to define a model with SCModel, see Models in an Extension. SCA 2019.2 or earlier: Define a model by extending Backbone.Model. See Frontend Models for more information. |
SuiteScript 2.0 MyCoolModule.SS2Model.js This file resides in: Workspace/ SuiteScript 1.0 MyCoolModule.Model.js This file resides in: Workspace/ |
SuiteScript Services |
SuiteScript is NetSuite’s proprietary scripting language that is based on JavaScript. Specifically, it is JavaScript which has access to new APIs, methods, and objects and can only be run on NetSuite servers. A service acts like a RESTful API endpoint. You can define various standard CRUD (create, read, update and delete) method handlers and then pass those on to other bits of code to deal with. When a response is ready, the service will then send it back to the frontend that called it. You can include SuiteScript 1.0 and 2.0 services in your extensions. |
SuiteScript 2.0 MyCoolModule.Service.ss This file resides in: Workspace/ SuiteScript 1.0 MyCoolModule. This file resides in: Workspace/ |
Backend Models |
Generally speaking, each SuiteScript service you develop should act purely as an API/handler and any required business logic should reside elsewhere. In the context of a service, use a backend model to perform the business logic of a request after a service has handled it. This logic can include functions like reading or writing records. While there is not a backend model class that you extend or call, best practice is to employ backend models to maintain parity between the frontend data layer and the backend data layer. |
Extension developer tools do not create a backend model. Store each backend model you create in the same directory as its corresponding service. For example: Workspace/ |
Extension Manifest |
A manifest file contains a map of the structure of your extension, as well as important metadata about what it does and what versions and products it is compatible with. If you use the extension developer tools to create a baseline extension, a manifest file is included automatically. |
Workspace/MyCoolExtension/manifest.json |
*Visible when you create a baseline extension using the default for each command-line option as described in Create a Baseline Extension.