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: Module name – The almond library requires all modules to have names. Named modules can be called by other modules. Array of modules this module depends upon – Passed in as an array of names as strings and then named in the callback’s parameters. Callback – The code that is returned when the module is called. Return an object – The returned object is the most important part of the module. You should define properties of this object that act as the module’s methods.	Acme.MyCoolExtension.MyCoolModule.js This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/ Javascript
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/MyCoolExtension/Modules/MyCoolModule/ Javascript
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_mycoolextension_mycoolmodule.tpl This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/Templates
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/MyCoolExtension/Modules/MyCoolModule/ Javascript SuiteScript 1.0 MyCoolModule.Model.js This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/ Javascript
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/MyCoolExtension/Modules/MyCoolModule/SuiteScript2 SuiteScript 1.0 MyCoolModule.ServiceController.js This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/SuiteScript
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/MyCoolExtension/Modules/MyCoolModule/SuiteScript
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

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:

Module name – The almond library requires all modules to have names. Named modules can be called by other modules.
Array of modules this module depends upon – Passed in as an array of names as strings and then named in the callback’s parameters.
Callback – The code that is returned when the module is called.
Return an object – The returned object is the most important part of the module. You should define properties of this object that act as the module’s methods.

Acme.MyCoolExtension.MyCoolModule.js

This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/ Javascript

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/MyCoolExtension/Modules/MyCoolModule/ Javascript

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_mycoolextension_mycoolmodule.tpl

This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/Templates

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/MyCoolExtension/Modules/MyCoolModule/ Javascript

SuiteScript 1.0

MyCoolModule.Model.js

This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/ Javascript

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/MyCoolExtension/Modules/MyCoolModule/SuiteScript2

SuiteScript 1.0

MyCoolModule.ServiceController.js

This file resides in: Workspace/MyCoolExtension/Modules/MyCoolModule/SuiteScript

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/MyCoolExtension/Modules/MyCoolModule/SuiteScript

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.

Related Topics