Nghĩa khác của bài viết này chính là hướng dẫn bạn xây dựng các tiện ích (plug-in) dành cho thư viện jQuery với các mã nguồn JavaScript đã có, hoặc bạn có thể viết mới. Bài viết này sẽ hướng dẫn các bước để xây dựng một tiện ích dành cho jQuery. Bạn vui lòng vào trang chi tiết để xem thêm.

• Demo
• Phóng to
• Tải lại
• Cửa sổ mới

Our team finds that we get the greatest leverage out of our existing collection of code snippets by organizing them into well structured, easy to maintain libraries of pluggable modules. This is the first article in a two part series. In this article, we take a whirl-wind tour of how to create reusable modules with front-end JavaScript code using the popular jQuery library. In my follow-up article, we will briefly examine the Web Storage technology that has come out of the HTML5 specification process and then show how simple it is to wrap it within a jQuery plugin.

If you go back and look through the last few web app projects you’ve completed, you probably will find that you have accumulated a variety of snippets of JavaScript that may have even been tweaked to be reused in follow-on projects. If you haven’t yet organized these bits of code in a particular way, you may want to consider leveraging an existing framework that provides well-defined structure for code reuse.

Our team primarily uses jQuery, a very straightforward and easy to use JavaScript library originally created by John Resig back in 2006. If you are new to jQuery, we recommend the excellent jQuery in Action book and jQuery’s own website for pointers to tutorials and documentation.

jQuery has two logical components. The base jQuery library includes a powerful CSS-like selector mechanism, easy methods to manipulate the DOM, rich effects, Ajax support, utilities, and more. The jQuery UI library provides a collection of user interface widgets. These two parts of jQuery form the basis of a rich ecosystem that is further enhanced with many plugins. Writing jQuery plugins is pretty straight-forward once you are familiar with the basic conventions.

Conventions Conventions

If jQuery is a fit for your project, you can utilize its conventions to reap the benefits of a consistent code style, logical approach to working with data, and to easily leverage other basic building blocks of code.

Three particular best practices are self-evident with a quick review of the jQuery community (see the plugin authoring guidelines for more details).

First, files, functions, data, and events should follow naming rules to help form and maintain namespaces. Files will typically use the pattern of “jquery-prefix-name-version.js”. “jquery” identifies the file as a jQuery compatible piece of code, often a plugin. “prefix” is an optional word, acronym, or hyphenated phrase that identifies an organization or group of related files. “name” is the name of the plugin. “version” is usually the major and minor version numbers of the code, e.g. jquery-webvanta-icon-picker-1.0.js.

Functions, data, and events should use specific techniques outlined in the jQuery Plugin Authoring guidelines to minimize conflicts between different plugins.

A second convention deals with the common issue of protecting your jQuery plugin from interference by other JavaScript libraries or function namespaces. It also typically includes a simple trick for safely accessing the shorthand “$” variable which holds a reference to the jQuery object. By defining a self executing anonymous function that forms a closure, you keep your code reasonably isolated:

  (function($){
    $.iconPicker = function() {

      // Your code goes here
    }
  })(jQuery);

The anonymous function runs as soon as it is defined, passing the global “jQuery” value as a parameter, where it gets assigned to the local parameter name “$”, which is then accessible to the internal scope of the function regardless of what “$” may be outside.

A third convention details how parameters are passed to your plugin. Rather than long and complicated function signatures with many individual parameters (e.g. icon-picker(element, color, size, effect, delay)), utilize the technique of passing in a single JavaScript literal object, which simulates a collection of name/value pairs. This makes for more readable code, and makes it easy to implement default values and to allow for arbitrary missing or added parameters:

  $.iconPicker({element: el, color: 'blue', size: 3, effect: 'shrink', delay: 1000});

You’ll use this technique most commonly when writing a plugin with many optional parameters. For Rubyists, this may look similar to using a tailing hash in the parameter list to pick up arbitrary or named parameters.

Plain Old Utility Function Pattern

Utility functions are typically small routines that accomplish some basic self-contained task, such as string or date-time manipulation, working with cookies, or logging information. In the jQuery world, the usual approach to organizing such code is to attach these functions off of the main jQuery namespace. Remembering our conventions discussed earlier, this might look like:

(function($){
  $.webvantaUtils = {};

  $.webvantaUtils.readCookie = function(name) {
      var ne = name + "=",

      ca = document.cookie.split(';');
      for(var i=0;i < ca.length;i++) {

        var c = ca[i];
        while (c.charAt(0)==' ') c = c.substring(1,c.length);

        if (c.indexOf(ne) == 0) return c.substring(ne.length,c.length);

      }
      return null;
    }
})(jQuery);

Note we have namespaced our cookie related function under a higher level namespace organized in this case by a company library.

Once defined, you can use such a function elsewhere via simple reference (you could use “$” rather than jQuery if you wish and you know that it isn’t being used for some conflicting purpose in the scope of the call):

var myUser = jQuery.webvantaUtils.readCookie('user_info');

Wrapped Set Function Pattern

If you have utilities that act on DOM elements, you should tie in to jQuery’s ability to operate on a collection of DOM elements called a wrapped set.

Instead of assigning our functions to the top-level jQuery namespace, we instead connect to the “fn” object, which gains us access to the wrapped set through the “this” variable.

Let’s say you have some utility code that counts how many times any of your form input elements contain a particular letter sequence:

(function($){
  $.fn.redAlert = function(badValue) {

    var badValueFound = 0;
    this.each(function() {
      if ($(this).val().toLowerCase().indexOf(badValue.toLowerCase()) >= 0)

        badValueFound = badValueFound + 1;
    });
    return badValueFound;

  };
})(jQuery);

We use the wrapped set found in the first “this” and call an iterator on it to walk through each value in the set. Within the function passed to the “each” iterator, the value of “this” changes to point to one of the wrapped set’s DOM elements. We can reconstitute that element as a jQuery object with the $(this) idiom, and use it as we wish…here to compare some string values.

You might use the plugin like so:

  if ($("form input:text").redAlert('Stink') > 0)
    alert("Something smells in the form");

In this contrived example, we are returning an integer value to accomplish our goals.

• Mã nguồn
• In

• Lời bình (1)
• Viết

bởi Xem

Hủy phản hồi

Viết lời bình của bạn

Tiêu đề bình luận

Tôi khẳng định 100% là người thực
Tôi lặp lại tôi không phải là công cụ máy

• Lượt gửi (0)
• Mới