---

Whether you are building a SugarCRM module, searching to find a module or researching the construction of a module you will find one thing to be consistent, they are all different. This is a proposal to standardize two different facets of a SugarCRM module. The two areas identified which require the most standardization are naming convention and folder architecture

Naming Convention

    Issue 1: What version of SugarCRM does this work on?

    Each module builder uses their own naming convention which generally leads to confusion for module adopters. When potential users are scrolling through the modules on SugarForge or CRMStage they have to rely on additional details on the site to provide which version of SugarCRM the module will work on. This means more data entry is required each time a module builder posts a new version. It also means that if this data is not added, the potential module adopter may have to sift through multiple modules causing a poor user experience.

    Proposal 1: SugarDev.net Naming Convention

    SugarDev.net recently posted an entry stating how they would name modules in the future. The naming convention is as follows:

    Module Name - Compatible SugarCRM Version - Module Version

    This would produce a module similar to: xyz-5.0-5.2-0.3.zip

Folder Architecture

    Issue 1: New Developers

    For new module developers it is often most convenient and efficient for them to look at existing code to learn current practices for building modules. Like SugarCRM, there are numerous ways to accomplish every task when constructing a module. This includes the layout of the folder structure and the way in which manifest files are constructed. By standardizing how modules are developed, the SugarCRM community can lower the barrier to entry for new module developers and increase the number of module submissions.

    Issue 2: Contributions

    Many of the modules on SugarForge are open source and the developers of those modules would likely enjoy contributions no matter how small. With a standardized way of building modules and folder structures a developer will spend less time getting up to speed on a module and more time contributing code.

    Issue 3: Customizations Don't Become Modules

     I have personally spoken to multiple individuals who decided not to turn customizations into modules simply because of the perceived complexities. This is a well understood issue to many developers who spent significant time building their first installable module. A standard can not only outline the adopted methods but augment the Developer Guide therefore increasing the likelihood of contributions.

    Proposal 1: Manifest Array Matching

    Manifest Array matching is where each array in the manifest file matches a corresponding folder. This structure is generally used for builders who heavily use the manifest file to outline their module structure. This is a very explicit way to to tell SugarCRM what is happening when a module is being installed. The benefit of this is that error reporting is more accurate when loading a module.

    For Example:

    If in your array you have vardefs, language and logic_hooks each with three entries then the folders would mirror that.

    Folders:
    /vardefs
    /language
    /logic_hooks

    Naming convention will also be important here as it is in module naming.

    If logic_hooks hold logic hook files for Accounts and Contact then the naming would be as follows

    /vardefs
    /language
    /logic_hooks
        Accounts_logic_hooks.php
        Contacts_logic_hooks.php


    Proposal 2: Module Matching

    Module matching is where the folder structure closely matches the copy array in the manifest file. This structure is primarily used by SugarCRM module builders that copy entire folders with many different file types. This structure is not explicit like Manifest Array Matching but is very convenient as the builder does not have write such a lengthy manifest.

    For Example:

    The manifest may rely heavily on the copy array which simply copies entire folders.

    The folder structure would be as follows

    /custom
        /modules
            /Accounts
            /Contacts

    All vardefs, language and logic hook files would reside in these folders.

In our Proposal for SugarCRM Module Standardization discussion on the SugarCRM forums we would like to hear you opinions and proposals on how to solve these issues and best structure modules. Through this discussion we will be able to formulate a specification that can help the SugarCRM community developers and consumers.