+

Search Tips   |   Advanced Search

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 how 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.


Contribution type: head

    CSS

    CSS placed inside the <head> element. Only valid in the co:head extension point. Use relative URLs for references to other resources such as images or other CSS documents.

    Static JavaScript

    JavaScript code, publicly cacheable, with no dependencies on the current browser, user, navigation state, or runtime context. Data source data works across all supported browsers with users downloading and saving the combined output as a static resource in a separate domain. Variables defined in the global scope can access context information provided outside the static script code. Some configuration can be static and cached across users pages, changing only when the server is restarted, such as values retrieved from Resource Environment Provider custom properties. This configuration typically has relatively short cache expiration for picking up potential configuration changes. The link to the URL that creates the aggregated content is part of a script tag.

    Dynamic JavaScript

    Configuration data used by JavaScript code that is susceptible to changing across pages or users, such as current locale, or URLs generated dynamically by the server. Contributions are written to the markup via an inline script element and are never cached. To avoid malicious code, escape values before serialization.

    Markup

    HTML in context of the extension point where they contribute to. Contributions to the co:head extension point can include markup valid for the <head> section of the page. Contributions to the co:config extension point can include markup valid inside the <body> tag. Use for contributions whose markup is not primarily visual but rather semantic, such as resource loading. Modules with visual markup must be documented and provided through a POC URI dynamic content spot, placed in 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 mapping data source might be used to map the POC URI to an alternative URI. We can associate a dynamic content with a module ID so the rendering of the data can be influenced by the profile used for the page. Portal render request-dependent attributes are not available in all cases. For example, when used in deferred mode, the render context is not available.


Contribution type: config

See the head section for details about each of these subcontributions.


Contribution type: dyn-cs

Define dynamic content spots through modules, instead of defining them through Resource Environment Providers. Allows overwriting dynamic content spots for different pages using different modules on the profiles. The only allowed subcontribution is markup.


Contribution type: menu

The only allowed subcontribution is JSON. See Menu framework.


Contribution type: xslt

The only allowed subcontribution is xslt. Use xslt to gather xslt resources along the module hierarchy.


Parent The module framework

Related concepts:
Simple menu framework
Dynamic content spots