Page Comparison

...

Almost every page supplied by our server will include a webcontext.js script tag. You won't find a webcontext.js file anywhere in the system, the content is actually supplied by an HTTP Servlet Filter. It's writes out several things which are critical for the execution of most of our client-side Javascript. Most calls to webcontext.js also include an additional "context" parameter telling it what area of the Platform it's intended for. This context is tied into the External Resources system described later.

WebContext performs writes out the following in order:

1. The global CONTEXT_PATH variable holding the webapp name if any.
2. The global FULLY_QUALIFIED_URL variable which holds the full URL of the server.
3. The base requireCfg configuration Object which is extended by plugins.
4. All External Resource scripts defined with the "requirejs" context. This is where plugins configure the RequireJS paths!
5. The SESSION_LOCALE variable containing the computed locale for the request
6. It then makes the call to configure the RequireJS system based on the "requireCfg" objectThe require.js and require-cfg.js files to initialize the RequireJS ystem.
7. Finally it loads the remaining External Resources entries with the "global" context and those matching contexts the current context for the request ("dashboards", "analyzer", etc.)

...

You'll notice several scripts are injected before the inclusion of require.js and require-cfg.js. These scripts are provided by the plugins and contain code extending the RequireJS configuration object. These As mentioned, they are provided through the External Resource system.

...

You'll notice the name of Analyzer RequireJS config script and all of the others included in the sample webcontext.js end with "require-js-cfg.js". This is important as the Spring Security white-list is allowing all requests ending with this to return un-authenticated. Analyzer's RequireJS configuration file are is pretty for our pluginstypical:

if(document.location.href.indexOf("debug=true") > 0){
	requireCfg['paths']['analyzer'] = CONTEXT_PATH+'content/analyzer/scripts';
} else {
	requireCfg['paths']['analyzer'] = CONTEXT_PATH+'content/analyzer/scripts/compressed';
}

It adds an "analyzer" root namespace to the "paths" entry. This is what routes requests for modules beginning with "analyzer/" to the appropriate URL location. The check for "debug=true" is changing the location where the system loads the scripts to allow developers to debug the system.so that the uncompressed files are available for debugging.

Helpful links!

https://github.com/amdjs/amdjs-api/wiki/AMD
http://requirejs.org/