SAPUI5 supports multiple module locations by means of the jQuery.sap.registerModulePath function.
In web applications, modules can be located in different locations, such as servers and web apps. A web application can, for example, be deployed as an individual web app and contain modules that have to be loaded at runtime. SAPUI5 and its modules, however, have to be loaded either from a content delivery network (CDN) or from a centrally deployed web app. By default, SAPUI5 loads modules from its resource root URL, that is, from the centrally deployed web application. This would fail for modules that are contained in your web application.
The jQuery.sap.registerModulePath function associates a module name prefix with a URL prefix. All modules whose names start with the module name prefix are loaded from the registered URL instead of the standard resource root URL:
jQuery.sap.registerModulePath = function(sModuleNamePrefix, sURL);
Thus, it is possible to redirect the request for the application-specific modules to the corresponding web application:
<!-- bootstrap tag which implicitly defines the resource root as 'http://www.sap.com/sapui5/1.0/resources/' --> <script src="http://www.sap.com/sapui5/1.0/resources/sap-ui-core.js" ></script> <script> // request will be mapped to http://www.sap.com/sapui5/1.0/resources/sap/ui/core/Core.js jQuery.sap.require('sap.ui.core.Core'); // redirect the 'my.webapp' package to the local web app jQuery.sap.registerModulePath('my.webapp', '/my-webapp/resources/my/webapp/'); // loads /my-webapp/resources/my/webapp/MyModule01.js jQuery.sap.require('my.webapp.MyModule01'); </script>
The registered URL above contains the transformed module name prefix 'my/webapp/'. This allows a more flexible packaging of the modules, for example, if you decide to deploy all modules named 'my.company.*' to the central URL 'http://my.company/shared/' without packaging them into a two level hierarchy of subfolders:
However, when the standard build tools of the SAPUI5 framework are used, the full package name will be part of the runtime file hierarchy and the registration must contain the transformed package hierarchy as above.