Contribution types
Modules can contribute different types of data to the extension points within the page.By specifying the type of data, a module can optimize hon that data is loaded on the page. For instance, all of the JavaScript contributions to the co:config spot from multiple modules can be loaded by a single request to the server. That request generates a single response containing the data for each contribution.
CSS
Contributions to this type must be valid Cascading Style Sheet (CSS) syntax and are always placed inside the <head> element, and is only valid in the co:head extension point.
Use generated CSS that uses relative URLs when referencing other resources like images or other CSS documents. By using relative URLs, resources can be resolved regardless of the context root in which they are placed.
Static JavaScript configuration
Contributions to this type must be valid JavaScript code, be publicly cacheable, and have no dependencies on the current user, navigation state, or runtime context.
It is common for static JavaScript code to use JavaScript variabledefined in the global scope to get access to context information that must be provided outside the static script code itself.
Some of this configuration might be static across pages and can change only when the server is restarted, such as values that are retrieved from Resource Environment Provider custom properties. This data can be loaded as an external script so that it can be cached across users and pages.
Because it is possible to change through configuration changes, this configuration typically has relatively short cache expiration times so that it is still publicly cacheable but can still expire to pick up potential configuration changes.
The link to the URL that creates the aggregated content is part of a script tag.
Important: It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code.
For example, configuration values read by a data source should be escaped before serializing the data.
Dynamic JavaScript configuration
Some configuration data used by JavaScript code is dynamic and susceptible to changing across pages or users. This configuration includes data, such as the current locale or URLs that are generated dynamically by the server.
Contributions to this type must be valid JavaScript code and are written to the markup inside an inline script element so that they are never cached.
Important: It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code.
For example, configuration values read by a data source should be escaped before serializing the data.
JavaScript code
Contributione that add static JavaScript code are added it to this type so that it is properly cached and potentially optimized by the framework.
Contributions of this type should not vary based on the client to further optimize the code.
For example, do not use a data source that generates different data for different browsers to eliminate code paths that branch based on the browser type or version. Instead, the data source should generate the same data that works across all supported browsers. Users can then download and save the combined output as a static resource in a separate domain.
Important: It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code.
Markup
Contributions to this type must be valid HTML in context of the extension point where they contribute to. For instance, contributions to the co:head extension point can include markup that is only valid for the <head> section of the page. Alternatively, contributions to the co:config extension point can include markup that is only valid inside the <body> tag.
This type is best used for contributions whose markup is not primarily visual but rather semantic, such as resource loading.
Modules that have visual markup should be documented and provided through a POC URI dynamic content spot. We can place this contribution in a specific place within the theme template relative to the design of the theme. If these unique location-important markup contributions are intended to be configurable or modified by a user, the dynamic content spot mapping data source might be used to map the POC URI to an alternative URI. Also, we can associate a dynamic content spot with a module id so that the rendering of the data can be influenced by the profile used for the page.
It is best not to use portal render request-dependent attributes, because there is no guarantee that those attributes are available in all cases.
For example, when used in deferred mode, the render context is not available.
Parent: The module framework