JQuery Core

The built-in JQuery Core is declared in a JavaScript resource named jquery with SHARED scope. The resource consists of two script entities jquery and exo-jquery-alias.

<module>
      <name>jquery</name>
      <script>
         <name>jquery</name>
         <path>/javascript/exo-jquery-1.7.1.js</path>
      </script>
      <script>
         <name>exo-jquery-alias</name>
         <path>/javascript/exo-jquery-alias.js</path>
      </script>
   </module>

• jquery wraps a version of JQuery Core

• exo-jquery-alias wraps a JavaScript file defining custom alias

if (eXo.jQConflict) {
  var gj = jQuery.noConflict(true);
} else {
  var gj = jQuery.sub();
}

GateIn introduces the gj alias to deals with likely conflicts as real real production requires multiple versions of JQuery Core. With definition in exo-jquery-alias.js, that alias ensures following things:

1. gj always refers to GateIn 's own JQuery Core, no matter how other JQuery versions are deployed into GateIn.

2. As no extra JQuery Core version exists, the global variables $, jQuery are still active.

3. As various JQuery Core versions exist, the global variables $, jQuery refers to the last JQuery Core instance loaded into client's browser (*)

Due to (*), we suggest that code depending on GateIn 's JQuery Core use gj alias instead of $ or jQuery.

JQuery Plugin

To embed a JQuery plugin depending on built-in JQuery Core, the best solution is to insert a <script> element into jquery resource as we can see in the sample with jquery_plugin_depending_on_1.7.1 plugin.

<module>
      <name>jquery</name>
      <script>
         <name>jquery</name>
         <path>/javascript/exo-jquery-1.7.1.js</path>
      </script>
      <script>
         <name>jquery_plugin_depending_on_1.7.1</name>
         <path>path_to_plugin_file</path>
      </script>
      <script>
         <name>exo-jquery-alias</name>
         <path>/javascript/exo-jquery-alias.js</path>
      </script>
   </module>

As the jquery_plugin_depending_on_1.7.1 script is placed before exo-jquery-alias, the entire plugin code is loaded/initialized with JQuery Core 1.7.1 before the two global variables $, jQuery are eventually deactivated by exo-jquery-alias.

JQuery Core

Consider the circumstance where product owner has a portlet A working with JQuery Core 1.6.4 and they are forced to embed JQuery Core 1.6.4 due to certain conflicts between two versions 1.6.4 and 1.7.1. In this case, there are two solutions:

Declare a SHARED resource jquery-1.6.4 and make it a dependency of portlet A 's resource.

<module>
      <name>jquery-1.6.4</name>
      <script>
         <name>jquery-1.6.4</name>
         <path>/javascript/jquery-1.6.4.js</path>
      </script>
   </module>

<portlet>
    <name>A</name>
    <module>
       <depends>
          <module>jquery-1.6.4</module>
       </depends>
    </module>
</portlet>

Define a module in portlet A 's resource that points to JQuery Core 1.6.4.

<portlet>
    <name>A</name>
    <module>
       <script>
           <name>jquery-1.6.4</name>
           <path>/javascript/jquery-1.6.4.js</path>
       </script>
    </module>
</portlet>

If jquery-1.6.4 has various dependents, it should be configured as SHARED resource and the first solution is encouraged.

JQuery Plugin

We assume that the portlet A in previous section need a plugin depending on jquery-1.6.4. It is expected to have the plugin code loaded/initialized with JQuery 1.6.4. There are two solutions as we can see in following configurations.

<module>
      <name>jquery-1.6.4</name>
      <script>
         <name>jquery</name>
         <path>/javascript/jquery-1.6.4.js</path>
      </script>
      <script>
         <name>jquery_plugin_depending_on_1.6.4</name>
         <path>path_to_plugin_file</path>
      </script>
   </module>

<portlet>
    <name>A</name>
    <module>
       <script>
           <name>jquery-1.6.4</name>
           <path>/javascript/jquery-1.6.4.js</path>
       </script>
       <script>
           <name>jquery_plugin_depending_on_jquery_1.6.4</name>
           <path>path_to_plugin_file</path>
       </script>
    </module>
</portlet>