Building modules

Module pattern

It is highly recommended to have a common guideline for building modules.

This page describes the current structure and how it is implemented at the moment.

The main idea is to have everything modular, by following the JavaScript module pattern. We will be not able to strictly follow it, since we need to be backwards compatible, but it seems to be the right way...

In case you are interested in this topic, take a look at the article JavaScript Module Pattern: In-Depth where it is described very well.

The basic CONTENIDO module structure looks like

(function(Con, $) {
    // your module code here...
    // now you have access to all properties of the Con object and to jQuery by using $
})(Con, Con.$);

It is a self executing anonymous function, also known as Immediately-Invoked Function Expression (IIFE), which gets two parameters, the global Con object and the reference to CONTENIDO Backends jQuery instance. The main reason to pass additionally Con.$, which is not really needed, is to make it simpler for developers while writing module code. We all are used to deal with $ object, writing code with Con.$ could be confusing...

When needed, you can also pass the window object to the anonymous function

(function(Con, $, scope) {
    // now you have also access to window object by using scope
})(Con, Con.$, window);

Implementing a new module

Since JavaScript is flexible, thee are several ways to write JavaScript based modules. The following examples will not show all possible ways...

Each module should contain following basic structure

(function(Con, $, scope) {
    'use strict';

    var NAME = 'my-module-name';
    // your module code here...
})(Con, Con.$, window);

The 'use strict' statement within the function tells the interpreter to be more strict with the written JavaScript code, it helps us developers to write better code! Read the article ECMAScript 5 Strict Mode, JSON, and More, if you are interested in it.

Note

While it is recommended to use this statement for new modules, it should be used carefully in old sources, since it may break the application logic.

The variable (constant) NAME holds the name of the module. While it is not truly necessary, it may be helpful to define the module name here, e. g. for debugging reasons.

Implement a class like module

(function(Con, $) {
    'use strict';
 
    // Module name, lowercase and dashes!
    var NAME = 'my-module';
 
    // Module constructor function
    var MyModule = function(name) {
        this._name = name;
    };
    // Module instance function
    MyModule.prototype.sayHello = function() {
        alert('Hi ' + this._name);
    };
 
    // Assign module implementation to Con object
    Con.MyModule = MyModule;
})(Con, Con.$);

Note

Using the strict mode may result in different behaviors in different browsers. It is better not to use it, if you don't know the effects.

Then you could use something like

Con.Loader.get('path/to/my-module.js', function() {
    var obj = new Con.MyModule('Jane Doe');
    obj.sayHello();
});

or simply require the JavaScript source file and use the module

<script type="text/javascript" src="scripts/my-module.js"></script>
<script>
var obj = new Con.MyModule('Jane Doe');
obj.sayHello();
</script>

Implementing jQuery plugin

It is also possible to implement a jQuery plugin if needed...

(function(Con, $) {
    'use strict';
    $.fn.myPluginName = function () {
        // put your plugin logic here
    };
})(Con, Con.$);

Note

Using the strict mode may result in different behaviors in different browsers. It is better not to use it, if you don't know the effects.