⁠Chapter 34. Native AMD Modules

34.1. Difference in Native AMD and Portal Modules
34.2. Native AMD Modules hosted on CDN
34.3. Mapping path entries for AMD Modules
34.4. Fallback Paths
34.5. Example to Ensure Portal wide Consistency in mapping paths
The support for native AMD modules is added to RedHat JBoss Portal Platform. Native AMD modules exhibit three main differences againstJBoss Portal Modules:
  • Simplified declaration in gatein-resources.xml.
  • No server-side wrapping of JavaScript code.
  • Shared scope only.
Report a bug

⁠34.1. Difference in Native AMD and Portal Modules

Despite the great flexibility of Red Hat JBoss Portal Platform Modules, there are situations where they cannot provide an appropriate solution. For example, to use a large 3rd party JavaScript framework such as which complies with the AMD specification and it should be possible to declare Dojo modules as JBoss Portal Modules, but for certain reasons is not possible:
  1. Large Dojo 1.9.2 contains as many as 4899 JavaScript files. You declare them in gatein-resources.xml using a tool. But such a tool will have to provide the dependency tree which is not trivial.
  2. Extreme AMD.although AMD compliant consist of constructs, that JBoss Portal cannot handle such as:
    1. Relative module names. If you have a dependency graph as: dojo/sniff depends on dojo/has. Given that both dojo/sniff and dojo/has live in the same directory named dojo, the dojo/sniff.js file can start with define(["./has"], function(has){, but relative module path names such as "./has" cannot be handled by JBoss Portal modules.
    2. Cyclic dependencies occur in AMD Modules but JBoss Portal capitulates with an error when seeing them.
    3. Inline calls such as, require([id == 'platform' ? platformId : defId], function(provider){...}); are allowed in AMD but cannot be declared in JBoss Portal modules. There are two problems with such calls, you do not know at development time what dependency to declare in gatein-resources.xml and the JBoss Portal module implementation does server-side wrapping of all the modules which causes that these inline require() calls result in a request for a nonexistent resource.
    4. Loader Plugins. Specific loader plug-ins are supported in JBoss Portal. In AMD, the string following the ! separator, which is the resource ID is interpreted by the loader plug-in,so it can be interpreted incorrectly as a URL, name of another module,and so on. But the JBoss Portal module implementation is able to interpret them as resource paths.
Report a bug

⁠34.2. Native AMD Modules hosted on CDN

Red Hat JBoss Portal supports AMD modules hosted outside of the portal, for example modules hosted on a Content Delivery Network (CDN).

Important

The code snippets used in the section are under development at ArcGis Gears Portlet hosted on GitHub: https://github.com/ppalaga/arcgis-gears-portlet/commits/master
This feature is implemented using require.js path mappings listed at, http://requirejs.org/docs/api.html#config-paths The implementation allows to map a module ID prefix to an URL, instead of the prefix.
Report a bug

⁠34.3. Mapping path entries for AMD Modules

The mappings entries are declared in the <amd> section of the gatein-resources.xml file:
⁠

Example 34.1. AMD path entries in gatein-resources.xml

<gatein-resources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_resources_1_5 http://www.gatein.org/xml/ns/gatein_resources_1_5"
    xmlns="http://www.gatein.org/xml/ns/gatein_resources_1_5">

    <amd>
        <path-entry>
            <prefix>dojo</prefix><target-path>//js.arcgis.com/3.9/js/dojo/dojo</target-path>
        </path-entry>
        <path-entry>
            <prefix>dijit</prefix><target-path>//js.arcgis.com/3.9/js/dojo/dijit</target-path>
        </path-entry>
        <path-entry>
            <prefix>dojox</prefix><target-path>//js.arcgis.com/3.9/js/dojo/dojox</target-path>
        </path-entry>
        <path-entry>
            <prefix>esri</prefix><target-path>//js.arcgis.com/3.9/js/esri</target-path>
        </path-entry>
    </amd>
Report a bug

⁠34.4. Fallback Paths

You can assign multiple target paths to a given prefix. These multiple paths are interpreted as fallback paths.
For example, you can insert a third-party CDN URL as the first choice and add a URL on your own server as a fallback URL.
⁠

Example 34.2. Adding Fallback paths to gatein-resources.xml

...
    <amd>
        <path-entry>
            <prefix>dojo</prefix>
            <target-path>//js.arcgis.com/3.9/js/dojo/dojo</target-path>
            <target-path>//mycompany.com/frameworks/dojo/1.9.1</target-path>
        </path-entry>
        ...
    </amd>
...
For more information on fallback URL, see http://requirejs.org/docs/api.html#pathsfallbacks

See Also:

Report a bug

⁠34.5. Example to Ensure Portal wide Consistency in mapping paths

There is one global path mappings collection for each Portal instance. When a portlet application is deployed on JBoss Portal, the Portal can only accept path mappings which are consistent with the paths declared earlier by other applications.
For example, application app2 wants to register the AMD module ID prefix /dojo to be mapped to target path http://fastcdn.com/dojo/1.7.0
The prefix /dojo was previously registered by another application app1 to point to a different target path http://othercdn.com/dojo/1.9.1 .
Adding the prefix /dojo to the available prefixes could break app1 and no JavaScript or CSS resources from app2 will be accepted by the portal.
But to resolve this scenario, you can add the same mapping multiple times as shown below:
The path mapping from app2.war is accepted by the portal because it does not introduce any inconsistency.
Report a bug