Response title
This is preview!
Move this topic
jQuery Plugin Pattern 2.0
in Developing jQuery Plugins
•
1 year ago
Hi everyone,
After a long time I've finally written up my latest plugin pattern that allows to namespace your plugin, use traditional OOP method conventions, as well as maintaining full backward compatibility with jQuery's traditional plugin convention.
This means now you can write plugins that can be used like $(selector).pluginName.object.method() or even as $(selector).pluginName(args) or even as $(selector).pluginName(args).method() and of course you can pass arguments to your methods as well
. Have it anyway you want, nothing is stopping you from having something as granular and complex as $(selector).pluginName.object.object.object.method(args).object.method(args).method(args).fadeIn("slow").
Read more about it at my blog jQuery Plugin Pattern 2.0 .
This pattern improves upon my original attempt at this, and so far I know of no known issues. Feel free to discuss.
Milan
After a long time I've finally written up my latest plugin pattern that allows to namespace your plugin, use traditional OOP method conventions, as well as maintaining full backward compatibility with jQuery's traditional plugin convention.
This means now you can write plugins that can be used like $(selector).pluginName.object.method() or even as $(selector).pluginName(args) or even as $(selector).pluginName(args).method() and of course you can pass arguments to your methods as well
. Have it anyway you want, nothing is stopping you from having something as granular and complex as $(selector).pluginName.object.object.object.method(args).object.method(args).method(args).fadeIn("slow").Read more about it at my blog jQuery Plugin Pattern 2.0 .
This pattern improves upon my original attempt at this, and so far I know of no known issues. Feel free to discuss.
Milan
1
Replies(6)
Re: jQuery Plugin Pattern 2.0
1 year ago
Why break away from the common pattern of $(selector).plugin("method", args) for secondary methods? This seems to be a a well understood and accepted pattern. (am I missing something?)
It seems like you are putting all your functions into the main plugin scope. This doesn't feel like its makes the code very manageable. Why not do those declarations inside the outer chroming. They are just as visible and allow you to better separate your methods.
I'm not following the reason for separate getter/setter methods for the config. Would seem like a simple existence check against arguments with an if/else block would do the same thing with less code.
You have some extra metadata code that feels extraneous. What is the thought behind that?
Thanks
Re: jQuery Plugin Pattern 2.0
1 year ago
Those are some good questions you raise which is why I've responded to some of them on my blog at the bottom.
In short this pattern does not break away but extends a plugin's capability to be more in line with OOP conventions. Keep in mind that this plugin pattern is fully backwards compatible with jQuery's official pattern.
The functions are indeed defined inside the plugin's scope. In this pattern you have to go back to thinking OOP and not jQuery for a while to fully appreciate what's happening. Here your plugin becomes a class (in OO terms - and not a plugin in jQuery terms) and as is the convention in OOP, the methods are defined therein. This allows for them to be private, and then exposed as public in the traditional sense (by referencing the private method and linking it up to <i>this</i> via a public interface). The only difference here is that I had to create a wrapper (the underscore function), instead of a direct reference. This is needed for the magic to be made possible. Overall it's not too obtrusive and stays in line with the convention of using an underscore to refer to something private.
Just as a small reminder, keeping in line with OOP conventions allows us to do cool things like inheritance. For this reason alone you would not want to do these declarations outside of the Class. Furthermore, you do <i>not</i> want to necessarily expose all your methods to the outside world when you distribute your plugin. This pattern allows you to easily control that by adhering to JavaScript object oriented conventions. To answer your question in other words, the goal is not to make everything visible and separate, but select what you want to make visible via the equivalent of an interface (as known in other OO languages) and <i>group</i> your methods (internally) to logical groupings (e.g. classes).
The other good point that you've raised, that many jQuery developers wonder about, is in regards to the getters and setters. Most jQuery developers don't use them because jQuery by nature is not OO so getters and setters are more or less seen as bloat, unnecessary, or not even used. This pattern promotes jQuery developers to think OO-ish. So thank you for raising this question as it will hopefully clarify the concept to a wider audience.
The configs, and all other data for that matter, should be accessed via getters and setters. Why? Because it allows you to prepare your code for added logic when such data is accessed or set. In other words, we can take advantage of the concept of getters and setters. In my example I keep it very simple and lean. However, in your practical development you may want to attach logic to your data structures. Whatever you do you do not want to edit the _config, or any other shared data structure for that matter, directly because it's just storage - see it as a black box. The getter and setter actually handles the know-how of that structure. In my example it's the initConfig that does that and simply uses setConfig as a tunnel to pass the configurations via jQuery's extend() to _config - as you can see in the code.
Just to quickly explain it in plain words: Inside your code you do not want to care about how the _config gets populated. All you want to do is that whenever you call getConfig() somehow you have access to the data - this is where the setter comes in. You only set it once, and going on forward regardless of where you are in the code, you know that getConfig() will get you what you need - one way or another. If you would <i>not</i> have getters/setters you would indeed need to sprinkle your code with if/then's. This is not good practice as it introduces many potential points of failures - whereas getters and setters reduces that to two (one getter and one setter), and it allows for bloat to make its way into the code. Again, reading up on the benefits of using getters and setters in general object oriented programming will better explain this than I can in one or two paragraphs. Basically you just want to have access to your data and you don't care how.
I'm not sure what metadata you refer to as my example is as lean as I could think of to accomplish the intended goal. If there is a part that you do not understand, feel free to point out the exact code and I can break it down and I'm always open to fine-tune anything that can be done a better way with the same results.
I still have to break apart this pattern in my blog as it does at first sight not make sense, but when you will play with it for a while (and play with a debugger) things will slowly start to make sense. Think of the first time you got introduced to C's pointers.
I appreciate your questions and hope you will get a chance to apply this pattern to a plugin.
Let me know of further questions, comments, or ideas...
Milan Adamovsky
In short this pattern does not break away but extends a plugin's capability to be more in line with OOP conventions. Keep in mind that this plugin pattern is fully backwards compatible with jQuery's official pattern.
The functions are indeed defined inside the plugin's scope. In this pattern you have to go back to thinking OOP and not jQuery for a while to fully appreciate what's happening. Here your plugin becomes a class (in OO terms - and not a plugin in jQuery terms) and as is the convention in OOP, the methods are defined therein. This allows for them to be private, and then exposed as public in the traditional sense (by referencing the private method and linking it up to <i>this</i> via a public interface). The only difference here is that I had to create a wrapper (the underscore function), instead of a direct reference. This is needed for the magic to be made possible. Overall it's not too obtrusive and stays in line with the convention of using an underscore to refer to something private.
Just as a small reminder, keeping in line with OOP conventions allows us to do cool things like inheritance. For this reason alone you would not want to do these declarations outside of the Class. Furthermore, you do <i>not</i> want to necessarily expose all your methods to the outside world when you distribute your plugin. This pattern allows you to easily control that by adhering to JavaScript object oriented conventions. To answer your question in other words, the goal is not to make everything visible and separate, but select what you want to make visible via the equivalent of an interface (as known in other OO languages) and <i>group</i> your methods (internally) to logical groupings (e.g. classes).
The other good point that you've raised, that many jQuery developers wonder about, is in regards to the getters and setters. Most jQuery developers don't use them because jQuery by nature is not OO so getters and setters are more or less seen as bloat, unnecessary, or not even used. This pattern promotes jQuery developers to think OO-ish. So thank you for raising this question as it will hopefully clarify the concept to a wider audience.
The configs, and all other data for that matter, should be accessed via getters and setters. Why? Because it allows you to prepare your code for added logic when such data is accessed or set. In other words, we can take advantage of the concept of getters and setters. In my example I keep it very simple and lean. However, in your practical development you may want to attach logic to your data structures. Whatever you do you do not want to edit the _config, or any other shared data structure for that matter, directly because it's just storage - see it as a black box. The getter and setter actually handles the know-how of that structure. In my example it's the initConfig that does that and simply uses setConfig as a tunnel to pass the configurations via jQuery's extend() to _config - as you can see in the code.
Just to quickly explain it in plain words: Inside your code you do not want to care about how the _config gets populated. All you want to do is that whenever you call getConfig() somehow you have access to the data - this is where the setter comes in. You only set it once, and going on forward regardless of where you are in the code, you know that getConfig() will get you what you need - one way or another. If you would <i>not</i> have getters/setters you would indeed need to sprinkle your code with if/then's. This is not good practice as it introduces many potential points of failures - whereas getters and setters reduces that to two (one getter and one setter), and it allows for bloat to make its way into the code. Again, reading up on the benefits of using getters and setters in general object oriented programming will better explain this than I can in one or two paragraphs. Basically you just want to have access to your data and you don't care how.
I'm not sure what metadata you refer to as my example is as lean as I could think of to accomplish the intended goal. If there is a part that you do not understand, feel free to point out the exact code and I can break it down and I'm always open to fine-tune anything that can be done a better way with the same results.
I still have to break apart this pattern in my blog as it does at first sight not make sense, but when you will play with it for a while (and play with a debugger) things will slowly start to make sense. Think of the first time you got introduced to C's pointers.
I appreciate your questions and hope you will get a chance to apply this pattern to a plugin.
Let me know of further questions, comments, or ideas...
Milan Adamovsky
Leave a comment on danatcofo's reply
Re: jQuery Plugin Pattern 2.0
1 year ago
Milan, can you provide a working example somewhere? Also, would it be too much to ask to provide well-formatted, consistently indented, syntax highlighted code, containing useful comments?
That being said, I don't see how what you've done can work reliably, since you're only setting jQuery.fn._plugin (which I'm guessing is what you're using to keep track of the current `this`) when jQuery.fn.init is called, and not anywhere else (like in any of the "destructive" jQuery.fn methods that change what `this` is, like .pushState and .end).
- Ben
(I posted this same comment on your blog)
http://bit.ly/benalmandotcom - "There's a Ben Alman jQuery plugin for that"
Re: jQuery Plugin Pattern 2.0
1 year ago
Leave a comment on cowboy.ben's reply
Re: jQuery Plugin Pattern 2.0
1 year ago
Milan, I'm getting SyntaxHighlighter error messages in both Chrome and Firefox, so I unfortunately don't see any syntax highlighting.
I'm also not sure leaving comments out is a great idea here, as brief contextual comments could save another programmer a substantial amount of time when analyzing your code.
Just so you know, I did try out your sample code, and it did nothing that I could see. What is it supposed to do? Is it supposed to alert a message?
And you didn't answer my question about jQuery.fn._plugin - You're setting this in your overridden jQuery.fn.init, but what about when the current jQuery collection changes due to destructive methods that use .pushStack or .end? What happens when you retain a reference to a jQuery collection, run jQuery.fn.init with a totally different selector, and then call a plugin method on the referenced collection?
You may be handling these use-cases, but I have no easy way of telling. As it stands now, it would be very difficult for me to use or recommend this pattern, due to the lack of transparency in what it does and any kind of proof of how reliable it is.
(I posted this same comment on your blog)
Leave a comment on cowboy.ben's reply
Re: jQuery Plugin Pattern 2.0
1 year ago
Leave a comment on milan.adamovsky's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to milan.adamovsky's idea
Statistics
- 6 Replies
- 2481 Views
- 0 Followers
