Style Guide & Naming Conventions

Project Structure

In Adobe Dx, all artifacts / modules / packages are separated into their area of concern. To date, we have:

1. Bundles - A common set of java classes for base functionality
2. Apps/admin - A set of utilities to aide authoring and administration
3. Apps/all - A content package to rollup all Dx dependencies
4. Apps/content - A set of components and code to support content components (marketo, etc.)
5. Apps/docs - A set of components and templates to support the Adobe Dx documentation site.
6. Apps/structure - A set of components to support structure components (Flex, Page, etc.)

There is an expectation that all app modules have a consistent project structure that also descend into finer areas of concern. For example, admin:

Admin Root

admin/app (Content Package)
admin/app/pom.xml
admin/app/package.json
admin/app/webpack.config.js
admin/core (Java Bundle)

If we explore the app content package further, we can see these finer areas of concern in the jcr_root folder:

admin/app/jcr_root/apps/dx/admin/clientlibs
admin/app/jcr_root/apps/dx/admin/components
admin/app/jcr_root/apps/dx/admin/content
admin/app/jcr_root/apps/dx/admin/services

This translates in AEM to:

/apps/dx/admin/clientlibs
/apps/dx/admin/components
/apps/dx/admin/content
/apps/dx/admin/services

We can also go deeper into areas of concern:

/apps/dx/admin/clientlibs/author
/apps/dx/admin/clientlibs/configs
/apps/dx/admin/clientlibs/manager
/apps/dx/admin/clientlibs/registry
/apps/dx/admin/components/configmanager
/apps/dx/admin/components/datasource
/apps/dx/admin/components/datasource/contextawaredatasource
/apps/dx/admin/content/config-manager
/apps/dx/admin/services/encryptValues

Clientlibs

If we have the following clientlib structure:

/apps/dx/admin/clientlibs/author
/apps/dx/admin/clientlibs/configs
/apps/dx/admin/clientlibs/manager
/apps/dx/admin/clientlibs/registry

This should naturally translate to the following categories:

dx.admin.author
dx.admin.configs
dx.admin.manager
dx.admin.registry

In cases of specific component needs, each component should have a modularized clientlib category:

dx.content.marketo.publish
dx.content.marketo.author

For Webpack, the following entry names would be used:

module.exports = {
    entry: {
        marketoPublish: [`${PROJECT_PATH}/marketoPublish/src/js/app.js`],
        marketoAuthor: [`${PROJECT_PATH}/marketoAuthor/src/js/app.js`],
    },
}

Please not the camel casing as this is a Javascript file, so we are using Javascript naming conventions.

It's not required to have an author clientlib for every component, but it's important to illustrate how this should be organized if the need is there.

Clientlibs in Components

Bad

/apps/dx/content/components/marketo/clientlib

Good

/apps/dx/content/clientlibs/marketo

Putting a clientlib in a component is considered an anti-pattern and should never be done. All javascript should be funneled through Webpack, eslint, Babel, and Jest to ensure they follow Adobe Dx style guide and test coverage can be evaluated.

Resource Types

Content

Javascript

LESS