jQuery Plugin Boilerplate, revisited

You are currently browsing comments. If you would like to return to the full story, you can read the full entry here: “jQuery Plugin Boilerplate, revisited”.

64 thoughts on “jQuery Plugin Boilerplate, revisited

  1. ionut

    Thanks for responding Stefan

    sorry to disturb you further but i’m new at javascript and jquery and i want to be sure i develop the plugin correctly
    can the plugin be called like this

        foo: 'test'
    }, function onFoo(data){ 
        do something with returned data
    }, function onBoo(data){ 
        do something 


    in the boilerplate you have

    onFoo: function() {}

    is that a function or what ?
    if i call the plugin like i said before is the onFoo called or i need to define the function like in your example

    plugin.onFoo = function(data) { return data; }

    not sure if i got the info correctly i want to define some functions that (return some data or not) in my plugin and let the user call the functions

    if i define a function can the user overwrite the functionality ?
    example i bind a function to be executed onclik how can i let the user define his own code and bypass my function ?

    thanks in advance for any response

    1. Stefan Gabos Post author

      you are making a confusion between public methods – methods that can be called from “outside” – and events which are fired by the plugin during different stages and are to be “hooked” from a custom function.

      for the public methods read the comments and the usage examples. let’s say you have a tooltip plugin and in it you may a have a public method named “close” that hides the “tooltip”. you’d use $(‘#element’).data(‘pluginName’).close().

      events are fired by the plugin during different stages and are to be “hooked” from a custom function. for our tooltip plugin we might want to have the “onClose” event. In this case, you’d replace “onFoo” with “onClose” (leave the function(){}) and in our public method called “close”, after all the code runs, we’d call “plugin.onClose()”. this way, if the user attached a custom function to the onClose() event, it will be executed when the tooltip closes.

  2. ionut

    thanks Stefan you have been a great help
    can you recommend some related books that will help me understand this thing better

  3. Max

    Hey Stefan,

    really love your plugin boilerplate and have used it a few times by now.
    I have one question however:

    Is there a specific reason why the init function is public?

  4. Harry

    I am very confused about using both $.pluginName and $.fn.pluginName. If the plugin will operate on the DOM why not just use the $.fn namespace.

    Also the code inside $.fn.pluginName doesn’t allow calling public methods with strings which is the most recommended way to call plugin methods according to http://docs.jquery.com/Plugins/Authoring

    1. Steve

      Like Harry I’m also confused with the two main types jquery plugin developing.

      1.) Your Type.
      As a former PHP developer i would prefer to have an class-object.
      So i really like your type of writing plugins.

      2.) The jQuery recommended way

      i Really like the way they call “public” methods.
      especially that part:

      $.fn.tooltip = function( method ) {
          if ( methods[method] ) {
            return methods[method].apply( this, Array.prototype.slice.call( arguments, 1 ));
          } else if ( typeof method === 'object' || ! method ) {
            return methods.init.apply( this, arguments );
          } else {
            $.error( 'Method ' +  method + ' does not exist on jQuery.tooltip' );

      But how can i use this type of “method-calls” with OO Instances!?
      I’m confused with mixing the two types.
      Is there any recommended way to do so?

    2. Stefan Gabos Post author

      i get this from many people 🙂 the recommended way is the way of jQuery; my way is the way it always was with JavaScript and, as you say, being also a PHP developer it really suits me.

      You can see many more ways of doing this at http://jqueryboilerplate.com/

  5. Fili

    Thanks for this excellent boilerplate, I use it often. Just out of curiosity; the second variable declaration in line below seems redundant, is that there pure for aesthetics?

    var $element = $(element), element = element;

    (ps. the captcha on this page is quite unreadable)

    1. Stefan Gabos Post author

      yes it is there so that both $element and element are visible side by side and users realize that there’s a difference

  6. Gustavo Sillero

    First of all, thanks for your work, it’s very handy 🙂
    So, I made a few additions suiting my needs, but I would like your opinion on this specific change:

    (function($) {
      var pluginName = "pluginName";
      $[pluginName] = function(element, options) {
      $.fn[pluginName] = function(options) {
        return this.each(function() {
          if (undefined == $(this).data(pluginName)) {
            var plugin = new $[pluginName](this, options);
            $(this).data(pluginName, plugin);

    this way you don’t need to remember to change every instance of pluginName and it can also be referenced inside for logging and other purposes

    1. Stefan Gabos Post author

      the code is perfectly ok I just don’t like how it looks 🙂 but it’s a subjective point of view

  7. Claire

    How would you use this to extend an existing plugin? say there is a $.fn.baseplugin you want to extend do you then use $.fn.baseplugin.myoverrides to build the overriding one?

  8. Falko

    I made a small modification to ease the access to public methods:

    $.fn.DialogPersonAuswahl = function (options) {
    if (options == undefined && $(this).data(pluginName) != undefined)
    return $(this).data(pluginName);
    return this.each(function () {
    if (undefined == $(this).data(‘DialogPersonAuswahl’)) {
    var plugin = new $.DialogPersonAuswahl(this, options);
    $(this).data(‘DialogPersonAuswahl’, plugin);


    Access methods:
    // first call creates the plugin
    // further calls access the plugins methods

  9. paul

    thanks for this, i read through the jquery docs for this and this is SOOO much easier to understand. thank you.

  10. Dmitriy

    Ii don’t understand in code, why whe declare pluginName like a method of jQuery object and then we declare pluginName like a method of object $.fn why we did that?

  11. ChrisG

    How do I access the actual element (e.g., input) in the init…

    $(element) comes up undefined for me.



  12. vsync

    what about plugins which are based on event delegation?
    your post is a bit old, you should update it. the last part:

    return this.each(function() {

    is not good if I have million elements..

  13. keuluu

    Thanks for this clear and powerful piece of code.
    I’m facing a problem with event delegation though…
    How would you manage event delegation from within a private method targeting another private method ?
    for example :

    var init_method = function() {
       $(obj).delegate('.trigger', 'click', handle_event);
    var handle_event = function() {
       // do something



Comments are closed.