- 浏览: 482687 次
- 性别:
- 来自: 深圳
文章分类
最新评论
-
mrluo735:
明显不对,INOUT参数也可以有多个!
MyBatis 3 中使用存储过程 -
qitianhuoshen:
问一下 如果 配合 datatables的 searchval ...
MyBatis 3 中使用存储过程 -
zhanggang807:
”这就是累积,不会被清理“ 这个例子解决了我疑惑很久的问题
NIO - 使用选择器 -
lIO01:
你能不能别用自己照片当头像?
Spring MVC 中的基于注解的 Controller -
xuxiaoyinliu:
Spring MVC 中的 forward 和 redirect
This article comes from http://www.learningjquery.com/2007/10/a-plugin-development-pattern
I've been developing jQuery plugins for quite a while now, and I've become rather comfortable with a particular style of plugin development for my scripts. This article is meant to share the pattern that I've found especially useful for plugin authoring. It assumes you already have an understanding of plugin development for jQuery; if you're a novice plugin author, please review the jQuery Authoring Guidelines first.
There are a few requirements that I feel this pattern handles nicely:
I'll cover these requirements one by one, and as we work through them we'll build a simple plugin which highlights text.
Claim only a single name in the jQuery namespace
This implies a single-plugin script. If your script contains multiple plugins, or complementary plugins (like $.fn.doSomething() and $.fn.undoSomething()) then you'll claim multiple names are required. But in general when authoring a plugin, strive to use only a single name to hold all of its implementation details.
In our example plugin we will claim the name "hilight".
And our plugin can be invoked like this:
But what if we need to break up our implementation into more than one function? There are many reasons to do so: the design may require it; it may result in a simpler or more readable implementation; and it may yield better OO semantics.
It's really quite trivial to break up the implementation into multiple functions without adding noise to the namespace. We do this by recognizing, and taking advantage of, the fact that functions are first-class objects in JavaScript. Like any other object, functions can be assigned properties. Since we have already claimed the "hilight" name in the jQuery prototype object, any other properties or functions that we need to expose can be declared as properties on our "hilight" function. More on this later.
Accept an options argument to control plugin behavior
Let's add support to our hilight plugin for specifying the foreground and background colors to use. We should allow options like these to be passed as an options object to the plugin function. For example:
Now our plugin can be invoked like this:
Provide public access to default plugin settings
An improvement we can, and should, make to the code above is to expose the default plugin settings. This is important because it makes it very easy for plugin users to override/customize the plugin with minimal code. And this is where we begin to take advantage of the function object.
Now users can include a line like this in their scripts:
And now we can call the plugin method like this and it will use a blue foreground color:
As you can see, we've allowed the user to write a single line of code to alter the default foreground color of the plugin. And users can still selectively override this new default value when they want:
Provide public access to secondary functions as applicable
This item goes hand-in-hand with the previous item and is an interesting way to extend your plugin (and to let others extend your plugin). For example, the implementation of our plugin may define a function called "format" which formats the hilight text. Our plugin may now look like this, with the default implementation of the format method defined below the hilight function.
We could have just as easily supported another property on the options object that allowed a callback function to be provided to override the default formatting. That's another excellent way to support customization of your plugin. The technique shown here takes this a step further by actually exposing the format function so that it can be redefined. With this technique it would be possible for others to ship their own custom overrides of your plugin נin other words, it means others can write plugins for your plugin.
Considering the trivial example plugin we're building in this article, you may be wondering when this would ever be useful. One real-world example is the Cycle Plugin. The Cycle Plugin is a slideshow plugin which supports a number of built-in transition effects נscroll, slide, fade, etc. But realistically, there is no way to define every single type of effect that one might wish to apply to a slide transition. And that's where this type of extensibility is useful. The Cycle Plugin exposes a "transitions" object to which users can add their own custom transition definitions. It's defined in the plugin like this:
This technique makes it possible for others to define and ship transition definitions that plug-in to the Cycle Plugin.
Keep private functions private
The technique of exposing part of your plugin to be overridden can be very powerful. But you need to think carefully about what parts of your implementation to expose. Once it's exposed, you need to keep in mind that any changes to the calling arguments or semantics may break backward compatibility. As a general rule, if you're not sure whether to expose a particular function, then you probably shouldn't.
So how then do we define more functions without cluttering the namespace and without exposing the implementation? This is a job for closures. To demonstrate, we'll add another function to our plugin called "debug". The debug function will log the number of selected elements to the Firebug console. To create a closure, we wrap the entire plugin definition in a function (as detailed in the jQuery Authoring Guidelines).
Our "debug" method cannot be accessed from outside of the closure and thus is private to our implementation.
Support the Metadata Plugin
Depending on the type of plugin you're writing, adding support for the Metadata Plugin can make it even more powerful. Personally, I love the Metadata Plugin because it lets you use unobtrusive markup to override plugin options (which is particularly useful when creating demos and examples). And supporting it is very simple!
Update: This bit was optimized per suggestion in the comments.
This changed line does a couple of things:
This line is added as the last argument to jQuery.extend so it will override any other option settings. Now we can drive behavior from the markup if we choose:
And now we can hilight each of these divs uniquely using a single line of script:
Putting it All Together
Below is the completed code for our example:
This design pattern has enabled me to create powerful, consistently crafted plugins. I hope it helps you to do the same.
I've been developing jQuery plugins for quite a while now, and I've become rather comfortable with a particular style of plugin development for my scripts. This article is meant to share the pattern that I've found especially useful for plugin authoring. It assumes you already have an understanding of plugin development for jQuery; if you're a novice plugin author, please review the jQuery Authoring Guidelines first.
There are a few requirements that I feel this pattern handles nicely:
- Claim only a single name in the jQuery namespace
- Accept an options argument to control plugin behavior
- Provide public access to default plugin settings
- Provide public access to secondary functions (as applicable)
- Keep private functions private
- Support the Metadata Plugin
I'll cover these requirements one by one, and as we work through them we'll build a simple plugin which highlights text.
Claim only a single name in the jQuery namespace
This implies a single-plugin script. If your script contains multiple plugins, or complementary plugins (like $.fn.doSomething() and $.fn.undoSomething()) then you'll claim multiple names are required. But in general when authoring a plugin, strive to use only a single name to hold all of its implementation details.
In our example plugin we will claim the name "hilight".
// plugin definition $.fn.hilight = function() { // Our plugin implementation code goes here. };
And our plugin can be invoked like this:
$('#myDiv').hilight();
But what if we need to break up our implementation into more than one function? There are many reasons to do so: the design may require it; it may result in a simpler or more readable implementation; and it may yield better OO semantics.
It's really quite trivial to break up the implementation into multiple functions without adding noise to the namespace. We do this by recognizing, and taking advantage of, the fact that functions are first-class objects in JavaScript. Like any other object, functions can be assigned properties. Since we have already claimed the "hilight" name in the jQuery prototype object, any other properties or functions that we need to expose can be declared as properties on our "hilight" function. More on this later.
Accept an options argument to control plugin behavior
Let's add support to our hilight plugin for specifying the foreground and background colors to use. We should allow options like these to be passed as an options object to the plugin function. For example:
// plugin definition $.fn.hilight = function(options) { var defaults = { foreground: 'red', background: 'yellow' }; // Extend our default options with those provided. var opts = $.extend(defaults, options); // Our plugin implementation code goes here. };
Now our plugin can be invoked like this:
$('#myDiv').hilight({ foreground: 'blue' });
Provide public access to default plugin settings
An improvement we can, and should, make to the code above is to expose the default plugin settings. This is important because it makes it very easy for plugin users to override/customize the plugin with minimal code. And this is where we begin to take advantage of the function object.
// plugin definition $.fn.hilight = function(options) { // Extend our default options with those provided. // Note that the first arg to extend is an empty object - // this is to keep from overriding our "defaults" object. var opts = $.extend({}, $.fn.hilight.defaults, options); // Our plugin implementation code goes here. }; // plugin defaults - added as a property on our plugin function $.fn.hilight.defaults = { foreground: 'red', background: 'yellow' };
Now users can include a line like this in their scripts:
// this need only be called once and does not // have to be called from within a 'ready' block $.fn.hilight.defaults.foreground = 'blue';
And now we can call the plugin method like this and it will use a blue foreground color:
$('#myDiv').hilight();
As you can see, we've allowed the user to write a single line of code to alter the default foreground color of the plugin. And users can still selectively override this new default value when they want:
// override plugin default foreground color $.fn.hilight.defaults.foreground = 'blue'; // ... // invoke plugin using new defaults $('.hilightDiv').hilight(); // ... // override default by passing options to plugin method $('#green').hilight({ foreground: 'green' });
Provide public access to secondary functions as applicable
This item goes hand-in-hand with the previous item and is an interesting way to extend your plugin (and to let others extend your plugin). For example, the implementation of our plugin may define a function called "format" which formats the hilight text. Our plugin may now look like this, with the default implementation of the format method defined below the hilight function.
// plugin definition $.fn.hilight = function(options) { // iterate and reformat each matched element return this.each(function() { var $this = $(this); // ... var markup = $this.html(); // call our format function markup = $.fn.hilight.format(markup); $this.html(markup); }); }; // define our format function $.fn.hilight.format = function(txt) {' return '<strong>' + txt + '</strong>'; };
We could have just as easily supported another property on the options object that allowed a callback function to be provided to override the default formatting. That's another excellent way to support customization of your plugin. The technique shown here takes this a step further by actually exposing the format function so that it can be redefined. With this technique it would be possible for others to ship their own custom overrides of your plugin נin other words, it means others can write plugins for your plugin.
Considering the trivial example plugin we're building in this article, you may be wondering when this would ever be useful. One real-world example is the Cycle Plugin. The Cycle Plugin is a slideshow plugin which supports a number of built-in transition effects נscroll, slide, fade, etc. But realistically, there is no way to define every single type of effect that one might wish to apply to a slide transition. And that's where this type of extensibility is useful. The Cycle Plugin exposes a "transitions" object to which users can add their own custom transition definitions. It's defined in the plugin like this:
$.fn.cycle.transitions = { // ... };
This technique makes it possible for others to define and ship transition definitions that plug-in to the Cycle Plugin.
Keep private functions private
The technique of exposing part of your plugin to be overridden can be very powerful. But you need to think carefully about what parts of your implementation to expose. Once it's exposed, you need to keep in mind that any changes to the calling arguments or semantics may break backward compatibility. As a general rule, if you're not sure whether to expose a particular function, then you probably shouldn't.
So how then do we define more functions without cluttering the namespace and without exposing the implementation? This is a job for closures. To demonstrate, we'll add another function to our plugin called "debug". The debug function will log the number of selected elements to the Firebug console. To create a closure, we wrap the entire plugin definition in a function (as detailed in the jQuery Authoring Guidelines).
// create closure (function($) { // plugin definition $.fn.hilight = function(options) { debug(this); // ... }; // private function for debugging function debug($obj) { if (window.console && window.console.log) window.console.log('hilight selection count: ' + $obj.size()); }; // ... // end of closure })(jQuery);
Our "debug" method cannot be accessed from outside of the closure and thus is private to our implementation.
Support the Metadata Plugin
Depending on the type of plugin you're writing, adding support for the Metadata Plugin can make it even more powerful. Personally, I love the Metadata Plugin because it lets you use unobtrusive markup to override plugin options (which is particularly useful when creating demos and examples). And supporting it is very simple!
Update: This bit was optimized per suggestion in the comments.
// plugin definition $.fn.hilight = function(options) { // ... // build main options before element iteration var opts = $.extend({}, $.fn.hilight.defaults, options); return this.each(function() { var $this = $(this); // build element specific options var o = $.meta ? $.extend({}, opts, $this.data()) : opts; //...
This changed line does a couple of things:
- it tests to see if the Metadata Plugin is installed
- if it is installed, it extends our options object with the extracted metadata
This line is added as the last argument to jQuery.extend so it will override any other option settings. Now we can drive behavior from the markup if we choose:
<!-- markup --> <div class="hilight { background: 'red', foreground: 'white' }"> Have a nice day! </div> <div class="hilight { foreground: 'orange' }"> Have a nice day! </div> <div class="hilight { background: 'green' }"> Have a nice day! </div>
And now we can hilight each of these divs uniquely using a single line of script:
$('.hilight').hilight();
Putting it All Together
Below is the completed code for our example:
// create closure (function($) { /** * plugin definition */ $.fn.hilight = function(options) { debug(this); // build main options before element iteration var opts = $.extend({}, $.fn.hilight.defaults, options); // iterate and reformat each matched element return this.each(function() { $this = $(this); // build element specific options var o = $.meta ? $.extend({}, opts, $this.data()) : opts; // update element styles $this.css({ backgroundColor: o.background, color: o.foreground }); var markup = $this.html(); // call our format function markup = $.fn.hilight.format(markup); $this.html(markup); }); }; /** * private function for debugging */ function debug($obj) { if (window.console && window.console.log) window.console.log('hilight selection count: ' + $obj.size()); }; /** * define and expose our format function */ $.fn.hilight.format = function(txt) { return '<strong>' + txt + '</strong>'; }; /** * plugin defaults */ $.fn.hilight.defaults = { foreground: 'red', background: 'yellow' }; // end of closure })(jQuery);
This design pattern has enabled me to create powerful, consistently crafted plugins. I hope it helps you to do the same.
发表评论
-
Node 的安装
2012-12-28 20:51 1443该篇文章讨论到是 linux 版的 node ... -
Web 前端经常用到的 JSON 对象,JSON 字符串,QueryString 之间的转换
2011-12-17 14:17 0在做 Web 前端时,经常要在 JSON 对象 ... -
jQuery 的原型关系图,让你快速对 jQuery 有个整体的把握
2010-07-12 20:07 4336若干个月前,在博客园中看到一篇文章,内容很简单 ... -
26 个 JQuery 使用小技巧(jQuery tips, tricks & solutions)
2010-03-01 17:17 3660The use of the jQuery l ... -
javascript 动态创建 <script> 节点所想到的其它问题
2009-12-12 22:12 5004最近公司的项目中,有一个模块需要调用集团提供的 ... -
JavaScript 面向对象程序设计
2009-09-05 14:18 1147近期在网上 ... -
jQuery 学习十四(工具函数)
2009-05-03 23:17 2298● jQuery.boxModel ... -
jQuery 学习十三(效果)
2009-05-02 11:02 2248● hide() /** * 隐藏显示的元素 ... -
jQuery 学习十二(事件)
2009-05-01 16:42 4515● ready(fn) /** ... -
jQuery 学习十一(CSS)
2009-05-01 13:49 1582● css(name) /** * 访问第一 ... -
jQuery 学习十(文档处理)
2009-04-27 20:28 1836● append(content) /** ... -
jQuery 学习九(筛选)
2009-04-21 18:46 2055● eq(index) /** * 获取第 ... -
jQuery 学习八(属性)
2009-04-14 20:11 3674● attr(name) /** * 取得第 ... -
jQuery 学习七(选择器)
2009-04-11 17:36 2446● 在指定的上下文搜索 /** * 在指定的 ... -
jQuery 学习六(多库共存)
2009-04-11 14:00 2216● jQuery.noConflict( ... -
jQuery 学习五(插件机制)
2009-04-11 10:41 1715● jQuery.extend(object) ... -
jQuery 学习四(数据缓存)
2009-04-10 19:59 2118● data(name) /** * 返回元 ... -
jQuery 学习三(对象访问)
2009-04-10 19:08 1693● get() /** * 通过 CSS 选 ... -
jQuery 学习二(核心函数)
2009-04-09 18:42 1933● jQuery(expression, ... -
jQuery 学习一(基础知识)
2009-03-30 16:45 1512● The jQuery wrapper ...
相关推荐
jquery 的经典 英文书 jQuery Plugin Development Beginner’s Guide.PDF
jQuery plugin for autocomplete - jQuery自动完成插件
The Basics of Plugin Development for IntelliJ IDEA. Alexey Efimov 1 This article helps you to quickly understand the basics of plugin development for IntelliJIDEA in order to start writing your own ...
Lazy Load Plugin for jQuery
Professional WordPress Plugin Development 英文原版wordpress 插件开发教程
Good practice for jQuery plugin development Methods for making elements draggable Ways to customize sortable lists How to implement and localize a datepicker Who this book is for This book is for...
、CSS和JavaScript知识的开发者,内容覆盖了jQuery知识体系的全部内容,包括jQuery Core、jQuery Plugin 、jQuery UI、jQuery Mobile以及大量第三方的插件库和2800多个应用jQuery技术的网页参考。
WordPress Plugin Development Cookbook(2nd) 英文mobi 第2版 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看此书详细信息请在美国亚马逊官网搜索此书
WordPress Plugin Development Cookbook(2nd) 英文epub 第2版 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看此书详细信息请在美国亚马逊官网搜索此书
jQuery Media Plugin Demo
Chapter 1: Preparing for WordPress Development 7 WordPress background 7 Extending WordPress 8 Understanding WordPress architecture 8 Templating 9 Introducing plugins 9 Summarizing architecture ...
jQuery输入格式的插件Masked Input Plugin 里面有完整例子
This is a wordpress plugin development essentials.
jquery.print-preview.js 浏览器打印插件
How to Write a plugin for JMeter
JQuery Cycle Plugin
jQuery Orbit Plugin 1.2.3
NULL 博文链接:https://ice-cream.iteye.com/blog/443497
JQuery validation plugin学习资料