Best Practices When Building Custom Modules
Overview
Sugar provides two tools for building and maintaining custom module configurations: Module Builder and Studio. As an administrator of Sugar, it is important to understand the strengths of both tools so that you have a sound development process as you look to build on Sugar's framework.
Goal
This guide will provide you with all the necessary steps from initial definition of your module to the configuration and customization of the module functionality. Follow these tips to ensure your development process will be sound:
Build Your Module in Module Builder
Build the initial framework for your module in Module Builder. Add all the fields you feel will be necessary for the module and construct the layouts with those fields. If possible, it is even better to create your custom modules in a development environment that mirrors your production environment.
Never Redeploy a Package
Once a module has been promoted to a production environment, we recommend only making additional changes in Studio.
- ./modules/
- ./custom/modules/
- ./custom/Extension/modules/
This includes workflows, code customizations, changes through Studio, and much more. It is imperative that this directive is followed to ensure any desired configurations remain intact. When working in Studio, you can make the following types of changes:
- Adding a new field
- Updating the properties of a field that has been deployed with the module
- Changing field layouts
- Creating, modifying, and removing relationships
Every Module in Module Builder Gets Its Very Own Package
While it is possible to create multiple modules in a package, this can also cause design headaches down the road. If you end up wanting to uninstall a module and it is part of a larger package, all modules in that package would need to be uninstalled. Keeping modules isolated to their own packages allows greater flexibility in the future if a module is no longer needed.
Create Relationships in Studio After the Module Is Deployed
This part is critical for success as relationships created in Module Builder cannot be removed after the module is deployed unless the package is updated and redeployed from Module Builder. We would like to avoid redeploying a module from Module Builder, as mentioned above. If you deploy the module and then create the relationships in Studio, you can update or remove the relationships via Studio at any future point in time.
Delete the Package from Module Builder Once It Is Deployed
Once the package is deployed, delete it from Module Builder so that it will not accidentally be redeployed. The only exception to this rule is in a development environment since you may want to continue working and testing until you are ready to move the module to your production environment. If you ever want to uninstall the module at a later date, you can do so under Admin > Module Loader.