Components

An ImageX component may be a custom built module, a feature or grouping of functionality that are generalized into a single "Feature" for re-usability.

For example the ImageX Wiki component is a grouping of functionality that has been exported as a Feature using the Features module. This "feature" is a re-usable component providing base functionality including but not limited to the content type definition, field bases and instances, pages, panels and views. This component also inherits (or has a dependency) of the ImageX Common Fields component.

Component Standards

Requirements

• All ImageX components must be built generically, not specific for a client, allowing for the re-usability of this component as a single "drop in" into any project. Specific client overrides are considered overrides and should be handled accordingly.

Requirements - Packaging and Naming

• All ImageX components must be apart of the ImageX package.
• All ImageX component machine names must be prefixed with imagex_.

Requirements - Dependencies

• All ImageX components must define absolutely all of their dependencies (relying on Features to automatically determine Features is not always reliable).
• All ImageX components must define and implement a drupal-org.make file that clearly describes the dependencies and how to "make" them (download, git pull, etc.) during the build process.

Requirements - Versioning

• All components require to have proper version tracking within the .info in which is auto incremented to allow for easy identification of the version. For example not using -dev but instead using dev+1 or -beta1 and so on.
• Active development on components must exist on the 7.x-y.x-dev (example: 7.x-1.x-dev) branch, however each release will be tagged (example: 7.x-1.x+dev1)
• Stable components of major minor versions will exist on the 7.x-1.x branch in which all versions will be tagged appropriately (7.x-1.1).

Requirements - Documentation

• All ImageX components must be packaged and bundled with current documentation at all times. There are a minimum of four documents that must be bundled with each component. These documents are: README.md, PROJECT_MANAGER.md, CLIENT.md, DEVELOPER.md. These documents (click the filenames for the templates and their description) provide critical information to internal employees of ImageX and clients.

Developing a Component

1. First begin by asking yourself, is this component specialized for Client X's needs? Or, can it be built in an inheritable and de-coupled fashion allowing for re-usability. We as an organization strive for building generic and de-coupled components.

2. a. If this component is client specific, discontinue reading and follow ImageX's standard practice for creating exportable features.

3. Once you, the developer, believes that the component you are about to embark on creating meets the criteria for an ImageX component, consult your Project Lead, the Development and Product Lead, and/or the Frontend Lead. Discuss with them how you will approach the development of this component and how it fits into the big picture.

4. Request that a new repository is created for this component.

5. Perform initial repository setup (example: create the 7.x-dev branch, set as default; create a .gitignore and README.md).

6. Fork the component repository to your GitHub account.

7. Begin developing your component while adhering to coding and component standards.

8. Export your component (ensure it meets all standards) and submit a Pull Request with your initial component version.

9. Reach out to either the Development and Product Lead, Frontend Lead and/or one of the Authorized Code Reviewers to inform them that you have a new ImageX component that requires review.

10. Continue developing and contributing :)

Component File Structure

Each component with a similar file structure. A typical component has the following pieces:

• includes directory: Should the component have any "includable" files, they should live here.
• modules directory: Should the component have extension modules, a modules directory with the extension modules should exist.
• .info file: A standard Drupal module's .info file.
• .module file: A standard Drupal module's .module file.
• .install file: A standard Drupal module's .install file.
• .gitignore file: A simple Git ignore file containing commonly ignored files such as the .DS_Store.
• drupal-org.make file: Can be empty with only the core and api properties specified; however this file typically lists and includes all dependencies for projects to be downloaded.
• README.md file: Makes use of this template Component-Documentation-Template:-README

Empty drupal-org.make file

core = 7.x
api = 2

Special Considerations

• Content type oriented components must NOT include additional_settings__active_tab_CONTENTTYPE variables.