Skip to content

Overview

Development

Overview

IDEs

API Explorer

Gloop Design Guidelines

In order to help and encourage the creation of clean and efficient Gloop code, the recommended guidelines below should be followed.

Naming conventions, keywords you should not use, and more!

The appendix contains a page discussing rules that also should be followed when it comes to naming and organizing Integrate packages, Integrate endpoints, services, models and beans, and other TORO Integrate-related components.

Exception Handling

By default, handling of exceptions is optional in Gloop. If a service throws an exception and is not caught, it will be propagated outside of the service. It is often preferable to handle the exception and provide a remedy to the error or a useful message explaining why the error occurred. This is especially true when a service is exposed via a Gloop REST or SOAP API.

Separation of Concerns

In most cases, a Gloop service should only have one function or purpose. Consider services used to delete entities; a bad example would be one that is used to delete multiple types of entities as shown in the following code:

1
2
3
// Usage: com.company.Delete( type, entity )
com.company.Delete( 'account', account )
com.company.Delete( 'contact', contact )

A better example would be to break down the Delete service's functionality into multiple services, like so:

1
2
com.company.account.DeleteAccount( account )
com.company.contact.DeleteContact( contact )