Is it a good practice to break the second plugin instance if we call it like this?

$(selector).defaultPluginName({
    start: 13,
    end: 37
}).defaultPluginName({
    start: 37,
    end: 42
});

It will not work since we allow the plugin only to be instantiated once per element. But to remove the if statement in our plugin definition is even not the best idea, or?

I would like to propose a small change to this plugin, showing how to add more functions to this plugin, since the init function, in most cases will not be enough. As I understand it, adding all functions that I want to use to the plugin's prototype is the recommended way of going about it. If I am incorrect I would appreciate feedback about what is the best way to add functions that I want to use in init(). :)

Thanks.

Haven't got around to any proper work on this, but suggesting a slight change to the declaration of the Plugin constructor here. You may / may not agree, and I admit it might not be that great of an idea, however have found this structural change quite useful myself.

Modifying structure slightly so that the Plugin constructor function is declared as a variable and adding an alias to the Plugin prototype object. This might ruffle some feathers, but adds a little more contextual meaning to extending the Plugin constructor.

Hi, could someone explain where I am going wrong. I'm trying to use the jQuery boilerplate but having trouble when adding functions and calling them:

/*!
 * jQuery lightweight plugin boilerplate
 * Original author: @ajpiano
 * Further changes, comments: @addyosmani
 * Licensed under the MIT license
 */

// the semi-colon before the function invocation is a safety
// net against concatenated scripts and/or other plugins
// that are not closed properly.
;(function ( $, window, document, undefined ) {

    // undefined is used here as the undefined global
    // variable in ECMAScript 3 and is mutable (i.e. it can
    // be changed by someone else). undefined isn't really
    // being passed in so we can ensure that its value is
    // truly undefined. In ES5, undefined can no longer be
    // modified.

    // window and document are passed through as local
    // variables rather than as globals, because this (slightly)
    // quickens the resolution process and can be more
    // efficiently minified (especially when both are
    // regularly referenced in your plugin).

    // Create the defaults once
    var pluginName = "defaultPluginName",
        defaults = {
            propertyName: "value"
        };

    // The actual plugin constructor
    function Plugin( element, options ) {
        this.element = element;

        // jQuery has an extend method that merges the
        // contents of two or more objects, storing the
        // result in the first object. The first object
        // is generally empty because we don't want to alter
        // the default options for future instances of the plugin
        this.options = $.extend( {}, defaults, options) ;

        this._defaults = defaults;
        this._name = pluginName;

        this.init();
    }

    Plugin.prototype = {
        
        init: function() {
            // Place initialization logic here
            // You already have access to the DOM element and
            // the options via the instance, e.g. this.element
            // and this.options
            // you can add more functions like the one below and 
            // call them like so: this.yourOtherFunction(this.element, this.options).

            $(this.element).each(function() {
                console.log('Main function');

                this.functionOne(this.element, this.options);
            });
        }, 

        functionOne: function(el, options) {
            console.log('functionOne');
            
            this.functionTwo(el, options);
        },

        functionTwo: function(el, options) {
            console.log('functionTwo');
        }
    };

    // A really lightweight plugin wrapper around the constructor,
    // preventing against multiple instantiations
    $.fn[pluginName] = function ( options ) {
        return this.each(function () {
            if (!$.data(this, 'plugin_' + pluginName)) {
                $.data(this, 'plugin_' + pluginName,
                new Plugin( this, options ));
            }
        });
    }

})( jQuery, window, document );

This simple calling of functions results in the following console log:

Main function

TypeError: this.functionOne is not a function
this.functionOne(this.element, this.options);

Did I miss something? Reading the comments in the script, I think I'm calling the functions correctly?

Thanks!

"...but you're interesting in learning if there a better ways..." to "...but you're interested in learning if there are better ways..."

I changed the example HTML files.

Changes in examples:

• Updated RequireJS to 2.1.4 version.
• Updated jQuery to 1.9.0 version.
• Updated jQuery UI to 1.10.0 version.
• Added doctype in examples.
• Removed the type attributes in script tags.

The link "Non Widget-factory widget" on your documentation page "https://github.com/jquery-boilerplate/jquery-patterns" leads to a 404 page not found. This is the linked url:

• https://github.com/jquery-boilerplate/jquery-patterns/blob/master/patterns/jquery.simplewidget.plugin-boilerplate.js%5D

The page (=your example) doesn't exist any more. Would be interested to see this lightweight alternative to jQuery UI widget factory.

Since we are still missing a jQuery boilerplate that demonstrates how to expose the plugin methods to the developer, similarly to the way that jQuery UI does it, I forked the jquery.basic.plugin-boilerplate. Waiting for your feedback on this.

I've forked and exended the documentation at hand with a style manifesto just like here: https://github.com/ieservices/idiomatic.js.

Why not adding it? ;)

Why not exending the documentation at hand with a style manifesto just like here: https://github.com/ieservices/idiomatic.js ?

Well, I started to add two examples in my fork. You can pull it. I'll send you a pull request.

Hi,

I was hoping this template could be updated so that it can support the ability to be called as $. defaultPluginName() so it can return a value (string, object, boolean) along with $(selector).defaultPluginName() so it can return a chain able object.

I'm actually trying to figure out how it's done and so for unsuccessful. I'll continue to look up how it's done to go along with this boilerplate.

It would be too hard if i say, that i hate @DiegoLopesLima's pull request, however instead of replacing the old one it is might the better choice to add a new one ;-)