My favorite design pattern to create a jQuery plugin is shown below.
Is there any reason to create a namespace for methods in the plugin? Specifically, my use of var privateMethods shown below?
(function($){
var privateMethods={};
privateMethods.method1=function(){alert('privateMethods1');};
privateMethods.method2=function(){alert('privateMethods2');};
privateMethods.method3=function(){alert('privateMethods3');};
var privateMethod1=function(){alert('privateMethods1');};
var privateMethod2=function(){alert('privateMethods2');};
var privateMethod3=function(){alert('privateMethods3');};
function privateFunction1(){
//Consider using this approach if there is significant script
alert('privateFunction1');
}
var defaults = { //private, right?
foo: 'bar'
};
var methods = {
init : function (options) {
var settings = $.extend({}, defaults, options);
return this.each(function () {
//do whatever
});
},
destroy : function () {
return this.each(function () {});
},
otherPublicMethod : function() {
return $(this).each(function(){
//do whatever
})
}
};
$.fn.myPlugin = 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.myPlugin');
}
};
}(jQuery)
);
Concerning the visibility of your methods outside your plugins scope there is no difference between
privateMethods.method
privateMethod1 = function(){}
function privateFunction(){}
On the other hand namespacing does not have any serious drawbacks apart from the slightly bigger size your jQuery plugin will have (easily mitigated by mini- and uglifying your code). The possible advantages are the possibilities to:
Introduce a logical structure to your code by breaking your methods into namespaced groups
Use well-known Javascript patterns around Namespaces, making your code readable and maintainable e.g.: http://addyosmani.com/blog/essential-js-namespacing/
Encapsulation. Gets relevant for plugins with massive code base
In conclusion: Overall I'd opt to use namespaces anytime.
Related
I have my javascript code as follow:
$(document).ready(function () {
//call of global functions
globalFunction1();
globalFunction2(); //create a new object inside
globalFunction3();
}
function globalFunction1() {
// do something directly with jquery selectors
var testObj1 = new object1($('#tree')); // this is called later in the function
testObj.doSomething();
}
function globalFunction2() {
// do other things
}
function globalFunction3() {
// do something directly with jquery selectors
}
//creating an object in js
var object1 = (function () {
var tree;
function object1($tree) {
tree = $tree;
});
}
object1.prototype.doSomething = function () {
.....
};
return fancyStructure;
})();
Normally I have more global functions and if possible I always try to create objects using the new keyword (as in Java or C#)
Now, I am asked to provide namespacing in order to avoid function conflict problems. Thing is I am not sure how to achieve that giving my current code and knowing that I need to keep the code Object Oriented.
Hence, I am wondering if there is a way to add some namespacing effisciently. Any suggestion will do as long as it is along the lines of adding a namespace.
Just put your functions into an Object:
var mynamespace = {
globalFunction1 : function() {
// do something directly with jquery selectors
var testObj1 = new object1($('#tree')); // this is called later in the function
testObj.doSomething();
},
globalFunction2 : function() {
// do other things
},
globalFunction3 : function() {
// do something directly with jquery selectors
}
}
and call the functions with
mynamespace.globalFunction1();
Or you could just define your namespace
mynamespace = {};
And later add the the functions with
mynamespace.globalFunction1 = function() {
//do something
};
Use objects as containers for your functions. This is the standard approach of code structuring in JS.
var namespace1 = {
func1: function() {},
func2: function() {},
}
var namespace2 = {
func1: function() {},
func2: function() {},
}
namespace1.func2();
You can store your OOP code in this namespaces:
var namespace3 = {
someObj: function() {},
create: function() { return new this.someObj(); },
}
namespace3.someObj.prototype = {
count: 15,
someFunc() {}
}
And you can easily extend them:
namespace3.anotherObj = function () {}
Edit
Regarding your example:
var fancyStructureWrapped = (function () {
var tree;
function fancyStructure($tree) {
tree = $tree;
});
fancyStructure.prototype.doSomething = function () {
.....
};
return fancyStructure;
})();
// add it to some namespace
someNamespace.fancyStructure = fancyStructureWrapped;
//create an instance
var fs = new someNamespace.fancyStructure();
//and use it
fs.doSomething();
If you're looking for a general approach to managing a growing JavaScript codebase, check out RequireJS and/or Browserify. Both are libraries that allow dividing your code up into modular bits (ie. AMD or CommonJS modules) and then referencing/importing between them. They include tooling for bundling these files into a single JS file when it's time to deploy a production build too.
I'm interested on how is realized the JavaScript pattern used, for example, in jQuery UI dialog:
$.dialog('mydialod').dialog('close');
ie I can't get how to reference back a constructor function after I created it in a jQuery compliant fashion.
EDIT
Just to clarify: what is really obscure to me is how I can have somewhere
$('#mydlg').dialog();
and then somewhere else
$('#mydlg').dialog("somecommand");
that even in absolutely different places seems to point back to the original instance.
I think, it is somehow related with this (jquery.ui.widgets.js ),
// create selector for plugin
$.expr[ ":" ][ fullName.toLowerCase() ] = function( elem ) {
return !!$.data( elem, fullName );
};
but really I'm too green in javascript / jquery to get what's happening.
I'm not sure how jQuery UI does it (you'd have to look at the source), but here's a way to do this https://gist.github.com/elclanrs/5668357
The advantage of using this approach is that you keep all your methods private instead of in the prototype by using a closure; a module pattern in this case.
Edit: Aight, got it. This is how I got it to work. This I'm calling the "Advanced jQuery Boilerplate". I added the methods to the prototype, I don't think it really makes a difference to keep them outside, and makes it easier to call methods within methods with this.method():
(function($) {
var _pluginName = 'myplugin'
, _defaults = {
};
function Plugin(el, options) {
this.opts = $.extend({}, _defaults, options);
this.el = el;
this._init();
}
Plugin.prototype = {
_init: function() {
return this;
},
method: function(str) {
console.log(str);
return this;
}
};
Plugin.prototype[_pluginName] = function(method) {
if (!method) return this._init();
try { return this[method].apply(this, [].slice.call(arguments, 1)); }
catch(e) {} finally { return this; }
};
$.fn[_pluginName] = function() {
var args = arguments;
return this.each(function() {
var instance = $.data(this, 'plugin_'+ _pluginName);
if (typeof args[0] == 'object') {
return $.data(this, 'plugin_'+ _pluginName, new Plugin(this, args[0]));
}
return instance[_pluginName].apply(instance, args);
});
};
}(jQuery));
Now I have two divs:
<div></div>
<div id="mydiv"></div>
And I can use the plugin like:
$('div').dialog({ n: 69 }); // initialize both divs
console.log($('#mydiv').dialog('method', 'hello world'));
//=^ prints "hello world" and returns instance
console.log($('#mydiv').data('plugin_dialog').opts.n); //=> 69
It's basically storing the instance of the plugin in data to be able to restore the options since this info is attached to the element. It's similar to how jQuery Boilerplate works.
This is called 'chaining pattern'.
Basic idea is that object methods return constructed instance, look at simplified example:
function Dialog (){
this.open = function(){
console.log('open dialog');
return this;
}
this.close = function(){
console.log('close dialog');
return this;
}
}
var d = new Dialog();
d.open().close();
Note 'return this' statement in every method.
I'm struggling with how best to combine javascript Classes and jQuery plugins. This question isn't very specific, what I'm hoping for is pointers to more resources.
Basically, I want to store state data and private methods in a class, and then extend each jQuery object which I call my plugin on to have those private methods and properties. Such that inside the plugin I can call methods directly off the jQuery object.
I read jQuery plugin design pattern (common practice?) for dealing with private functions, specifically David's answer, however this initializes a new Class each time, and thus can't be used to save the state of the object.
I also found http://fuelyourcoding.com/jquery-plugin-design-patterns-part-i/, which recommends creating a class and then storing it in .data().
I think ideally what I want to end up with is code that looks like
(function( $ ){
var methods = {
init : function( options ) { // Initialize each object with a state and private methods },
show : function( ) {
// testFoo() is a private method that checks the element's state
if(this.testFoo()){
// Relying on jQuery's html() method
this.html() = this.fooTemplate();
}
}
};
// Boiler plate plugin from http://docs.jquery.com/Plugins/Authoring
$.fn.myPlugin = function( method ) {
// Method calling logic
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.myPlugin' );
}
};
})( jQuery );
Finally, it doesn't seem like I can bake the private methods into the plugin directly because methods like "testFoo()" will return a boolean, and therefore aren't chainable.
Thoughts? Am I approaching this the right way? Is there another design pattern I should be using? Perhaps not using jQuery plugin architecture at all?
Here's a proposed solution. It combines few different approaches (John Resig's inheritance model and Alex Saxton's plugin inheritance model).
Define your inheritable plugin:
(function ($) {
My.Plugin = Class.extend({
/*
* Initialization (constructor)
*/
init: function (element, meta) {
var $meta = $.extend({ name: "pluginName" }, meta);
// Call the base constructor
this._super(element, $meta);
// TODO: Add custom initialization code like the following:
// this._testButton = $('.testButton', element).get(0);
},
/*
* Public methods
*/
show: function() {
alert('This is a public method');
},
/*
* Private methods
*/
// DEMO: Overriding the base _paint method:
_paint: function () {
// "this._super()" is available in all overridden methods
// and refers to the base method.
this._super();
alert('TODO: implement myPlugin._paint!');
}
});
// Declare this class as a jQuery plugin
$.plugin('my_plugin', My.Plugin);
})(jQuery);
Define Base class
(function () {
var initializing = false, fnTest = /xyz/.test(function () { xyz; }) ? /\b_super\b/ : /.*/;
// The base Class implementation (does nothing)
this.Class = function () { };
// Create a new Class that inherits from this class
Class.extend = function (prop) {
var _super = this.prototype;
// Instantiate a base class (but only create the instance,
// don't run the init constructor)
initializing = true;
var prototype = new this();
initializing = false;
// Copy the properties over onto the new prototype
for (var name in prop) {
// Check if we're overwriting an existing function
prototype[name] =
typeof prop[name] == "function"
&& typeof _super[name] == "function"
&& fnTest.test(prop[name])
? (function (name, fn) {
return function () {
var tmp = this._super;
// Add a new ._super() method that is the same method
// but on the super-class
this._super = _super[name];
// The method only need to be bound temporarily, so we
// remove it when we're done executing
var ret = fn.apply(this, arguments);
this._super = tmp;
return ret;
};
})(name, prop[name])
: prop[name];
}
// The dummy class constructor
function Class() {
// All construction is actually done in the init method
if (!initializing && this.init)
this.init.apply(this, arguments);
}
// Populate our constructed prototype object
Class.prototype = prototype;
// Enforce the constructor to be what we expect
Class.constructor = Class;
// And make this class extendable
Class.extend = arguments.callee;
return Class;
};
})();
Plugin Creation
(function ($) {
// The "inheritance plugin" model
// [http://alexsexton.com/?p=51][1]
$.plugin = function (name, object) {
$.fn[name] = function (options) {
var instance = $.data(this, name, new object(this, options));
return instance;
};
};
})(jQuery);
Calling your plugin from javascript:
$('#someElem').my_plugin({options: {}, data: {} /* you can modify your plugin code to accept anything */}).show();
Note:
Private methods here are marked as _methodName. It's pure convention. If you really want to hide them, you can use module pattern (google for it or here's one for starters: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth)
Is this what you're looking for?
we currently learn some Javascript stuff in a course at the university.
For that we implement a library for common tasks like show(), hide(), write and such things.
Currently im running with an implementation like:
var myLib_maker = function () {
/*
private scope
*/
var debuggingMode=true;
var currentElement=null;
/*
end private scope
*/
return {
getElement: function (id) {
var o;
if (typeof id === 'string') { o = document.getElementById(id); }
if (!!(o && o.nodeType !== 1)) {
throw {
name: 'Type Error',
message: 'Wrong node type at id: '+id
}
}
currentElement=o;
return this;
},
getCurrentElement: function() {
console.log(currentElement)
return currentElement;
},
isVisible: function () {
return this.getCurrentElement().style.display.toLowerCase() === "block";
},
show: function () {
this.debug("show "+this.getCurrentElement())
this.getCurrentElement().style.display = "block";
return this;
},
hide: function () {
this.debug("hide "+this.getCurrentElement())
this.getCurrentElement().style.display = "none";
return this;
},
toggle: function() {
this.debug("toggle "+this.getCurrentElement())
this.isVisible() ? this.hide(): this.show();
return this;
},
write: function (content){
this.debug("write to"+this.getCurrentElement().id);
var tg = this.getCurrentElement().tagName.toLowerCase();
if (tg === 'input' || tg === 'textarea') {
currentElement.value = content;
} else {
currentElement.innerHTML = content;
}
return this
},
debug: function (what) {
if (debuggingMode===true){
console.log("[DEBUG] "+what);
}
return this;
}
};
}
var myLib=myLib_maker();
Than I have an external function (for testing) to switch 2 textareas contents.
function switchEditors(id1, id2){
c1=myLib.getElement(id1).getCurrentElement().value;
c2=myLib.getElement(id2).getCurrentElement().value;
myLib.getElement(id1).write(c2)
myLib.getElement(id2).write(c1)
}
I first tried with the following code, which obviously does not work, cause I overwrite my private currentElement and so I write always to id2
function switchEditors(id1, id2){
tmp=myLib.getElement(id1).getCurrentElement().value
myLib.getElement(id1).write(myLib.getElement(id2).getCurrentElement().value)
myLib.getElement(id2).write(tmp)
}
But what I really wanted initially was not using a private currentElement variable.
The first implementation of the write method extended the Element Object
Element.prototype.write= function (content){
var tg = this.tagName.toLowerCase();
if (tg === 'input' || tg === 'textarea') {
this.value = content;
} else {
this.innerHTML = content;
}
return this;
}
and such the getElement function returned
document.getElementById(id)
I want cascading (I hope this is the right word -> I mean the myLib.getElement("myid").show().hide() concatenation thing) and getting direct access to
all Element attributes but we must not use global scope for our library, so I have to encapsulate my library in any way.
So is there an elegant way to use the cascading thing and be able to get a direct access to all attributes on an element object without implementing each method within the global element scope?
Or is my lib desing completely wrong and has to be done totally different.
If so, just tell me, I appreciate any help.
(I tried to figure out how jQuery actually implement these things, but didn't get a real clue how it is done ... too much code ... :) )
I hope I described my wishes and requirements. If not please ask for more specific details.
As you've figured out, the currentElement is shared between calls to getElement. Instead you could create a new instance of myLib-object with Object.create and bind currentElement to that.
getElement: function (id) {
var o, self = Object.create(this);
/* ... */
self.currentElement = o;
return self;
}
And use this.currentElement throughout so that each call uses its own current element.
While Magnar's solution will work with this (singleton) pattern, it is a better idea to avoid creating a whole new object each time you call getElement. There is a reason for creating "classes" instead of singletons.
You can do it like this:
var MyLib_Maker = (function () { // I capitalized the class as a helpful
// convention recommended by Douglas Crockford
// Private static vars
var debuggingMode = true;
var currentElement = null;
// Private static methods
function _myMethod (x, y) { // call below by _myMethod(3,4);
return x * y;
}
// Private instance methods (but only if called properly:
// invoke below by _instMethod.call(this, 3, 4); )
function _instMethod (x, y) {
return this.anInstanceNumber * x * y;
}
// Private instance properties (quite cumbersome but doable if you
// absolutely must--e.g., for classes whose objects need to be clean when iterated)
// See http://brettz9.blogspot.com/2009/02/true-private-instance-variables-in.html
// and http://brettz9.blogspot.com/2009/02/further-relator-enhancements.html
// (put the Relator inside the closure if you don't want it reusable (and public),
// but then your extending classes must be inside the closure too)
function MyLib_Maker (arg1, arg2) {
// I recommend the following check to allow your class to be
// instantiated without the 'new' keyword (as in jQuery/$):
if (!(this instanceof MyLib_Maker)) {
return new MyLib_Maker(arg1, arg2);
}
// Other constructor code here
// ...
}
// Methods added on the prototype benefit from merely
// providing a low-memory reference across all instances;
// this will avoid adding a whole new object unnecessarily
// into memory
MyLib_Maker.prototype.getElement = function () {
// ....
return this; // Keep the chain going (if not public
// properties, you could add a method which also avoids
// extending the chain, like $(el).get() in jQuery
};
return MyLib_Maker;
}()); // We can invoke immediately to wrap up the closure
// Usage example:
var mlm = MyLib_Maker(2, 3).getElement().doSomething();
By the way, what you describe is called chaining; cascading is used in the likes of CSS to indicate that like different waves out of a waterfall, one may write over the other, as you can do by writing rules which override prior ones in CSS.
And it is good you moved away from overriding the Element object because, whatever the browser incompatibilities, this is the worst kind of global namespace pollution because it affects all elements, increasing the chance that another library which depends on that method (or which is careless in overriding the built-in prototypes itself) may get you unexpected results.
I want to use the prototype javascript framework for its "class" and inheritance capabilities. For everything else I will be using jQuery. Is there a minimalist version of prototype that will give me just this functionality? I don't want the additional overhead of the entire library if I won't be using it all.
To be specific I want the class and inheritence capabilities that allow me to define classes as follows (examples from wikipedia):
var FirstClass = Class.create( {
// The initialize method serves as a constructor
initialize: function () {
this.data = "Hello World";
}
});
and to extend another class:
MyNewClass = Class.create( FirstClass, {
//Override the initialize method
initialize: function() {
//..
},
// ...more methods add ...
});
Plus I don't want conflicts between the frameworks (i.e. $ should only be used by jQuery..I only want prototype (or any other suggestion would be fine) for class creation / inheritance).
Inheritance.js was the model that the guys developing the Prototype library have been inspired from and I think it is what you where asking for.
Note: $super seems to be this.parent as stated in the comments below.
If you're looking for something minimalistic:
function clone(obj) {
if(typeof obj !== 'undefined') {
clone.prototype = obj;
return new clone;
}
}
function copy(dest, src) {
for(var name in src) {
if(src.hasOwnProperty(name))
dest[name] = src[name];
}
}
function classof(constructor) {
return {
extend : function(base) {
constructor.prototype = clone(base.prototype);
return this;
},
mixin : function(members) {
copy(constructor.prototype, members);
return this;
}
};
}
Example usage:
// base class:
function Foo(value) {
this.value = value;
}
classof(Foo).mixin({
inc : function() { ++this.value; }
});
// derived class:
function Bar() {
Foo.apply(this, arguments);
}
classof(Bar).extend(Foo).mixin({
dec : function() { --this.value; }
});
var bar = new Bar(42);
bar.inc();
bar.dec();
Don't mix Prototype and jQuery. My experience says they don't play nice together. My personal preference would be to use Prototype due to the superior syntactical sugar.
There's no way to disable Prototype's $-function. You can disable jQuery's use of $ via jQuery.noConflict() - but it's not perfect.
As #mhtiza said, use Interitance.js for the class-sugar if you decide to stick to jQuery.
For version 1.7.1 I deleted everything below line 1625 in the prototype.js file and I no longer have conflicts with bootstrap and jquery. And the Class.create function still works. The class.create is the only method I wanted as well.