We Keep Coding

What's the difference between these namespacing methods?

I'm new to JavaScript and am trying to understand how to use namespaces to avoid naming conflicts. So far, the two most popular methods I've found for creating namespaces are these:
Method 1:
var MYAPPLICATION = {
calculateVat: function (base) {
return base * 1.21;
},
product: function (price) {
this.price = price;
this.getPrice = function(){
return this.price;
};
},
doCalculations: function () {
var p = new MYAPPLICATION.product(100);
alert(this.calculateVat(p.getPrice()));
}
}
Method 2:
var DED = (function() {
var private_var;
function private_method()
{
// do stuff here
}
return {
method_1 : function()
{
// do stuff here
},
method_2 : function()
{
// do stuff here
}
};
})();
Is the difference that the second method allows you to have private methods and variables, since only what is inside of the object being returned will be globally accessible? Which of these methods is best (or is there a better way)?

If you write an API for other people, I think method two is better. Example：jQuery.
In a web page, I prefer method one. Example：stackoverflow
In method two, you can not read and write functions and variables that is private, so if there is a bug, you can not read something by developer-tools for debug.

Second method is called 'module' pattern. Makes it comfortable for developers to use your code. Self-invoking function creates scope, so you only expose methods that you want to make public by returning object that contains references to those methods (public API). Those methods can have a lot of private helper functions and variables that you keep private for your own use. Most of the libraries are written this way. It's generally good to structure your library like that.
Here's a link to the website that explains it well : http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html
First method is just the way to put all the related functions together. You can make those for personal use in your module. Example:
Calc.add(5,5), Calc.subtract(3,2), Calc.multiply(3,3);
add, subtract, multiply share same namespace because they are related.

Using JS OOP with PHP

I'm new at JS programming. I have to write a php webapplication which uses ajax calls for every action (can't reload the page). So I have the php code done, and the JS as well, but I don't know what does JS OOP mean. I did google search for hours, and all I could figure out was "JS has no classm but there are tricks". So I would like to ask you to lead me to the right way and show me how to make it right.
I have four js files:
content.js, function.js, onload.js and validate.js
For now, I only do care about the function.js. It has code only for the ajax calls. Their names are:
NewMember(), SearchMembers(), ShowDetails(), DeleteMembers() and EditMember()
I'm going to show you only the first function (I don't want to waste your time by duplicating since each function is totally similar)
function NewMember() {
if (checkFields() == true) {
Loading("start");
var dataArray = {
first_name : $('#first_name').val(),
last_name : $('#last_name').val(),
birth_date : $('#birth_date').val(),
home_phone : $('#home_phone').val(),
work_phone : $('#work_phone').val(),
email : $('#email').val(),
email_again : $('#email_again').val(),
country : $('#country').val(),
city : $('#city').val(),
address : $('#address').val(),
comment : $('#comment').val()
};
var JSONString = JSON.stringify(dataArray);
$.ajax({
type: 'POST',
url : 'adapter.php',
data: {
data : JSONString,
action : 'create' },
success: function(msg) {
alert(msg);
resetFieldValues();
SearchMembers();
},
error: function() {
alert("Oops! Something went wrong, please reload the page!");
}
});
}
}
My question is, how would you re-write this by using the JS OOP? Full code is not neccessary, but please give me "easy" answers since I'm really a newbie. I'm really confused :/ Thanks for your help!

JavaScript is a completely object-oriented language.
Instead of the Classical Inheritance model that programmers are usually familiar with, JavaScript has a unique take on things with its model of Prototypical Inheritance.
Consider classical inheritance in PHP:
<?php
class Arachnid {
public $legs = 8;
function crawl(){ /***/ }
}
class Spider extends Arachnid {
function creep(){ /***/ }
}
class OrbSpider extends Spider {
function buildBeautifulWeb(){ /***/ }
}
?>
This is arguably the simplest methodology in JavaScript for the same faculty:
function Arachnid () {}
Arachnid.prototype.legs = 8;
Arachnid.prototype.crawl = function () { return "crawling" };
function Spider () { /* this is a constructor, so don't define spider's methods in here -- they'd be redefined for every constructor call (each instance) */ }
Spider.prototype = new Arachnid(); // Spider inherits from a new basic Arachnid
Spider.prototype.constructor = Spider;
Spider.prototype.creep = function () { return "creeping" }; // Attach Spider's methods to its prototype for best performance
function OrbSpider () {}
OrbSpider.prototype = new Spider(); // we wholly overwrite the natural prototype to a basic arachnid
OrbSpider.prototype.constructor = OrbSpider; // so we must replace the constructor for instanceof to work
OrbSpider.prototype.buildBeautifulWeb = function () { return "webbing" };
// Testing
var orb = new OrbSpider();
console.log( orb.buildBeautifulWeb() ); //>> webbing
console.log( orb.creep() ); //>> creeping
console.log( orb.crawl() ); //>> crawling
console.log( orb.legs ); //>> 8
console.log( orb instanceof OrbSpider ); //>> true
console.log( orb instanceof Spider); //>> true
console.log( orb instanceof Arachnid); //>> true
In JavaScript, you create Prototype Chains. When you ask an object for a property, JavaScript will first check the object itself for that property -- if it isn't found, JavaScript will check the object's prototype object. If the property isn't there either, JavaScript will check that prototype object's own prototype -- and so on, and so forth, bubbling up the Prototype Chain until the property is found (or not).

JS means JavaScript. OOP means Object Oriented Programming. This is programming JavaScript in an OOP manner. It doesn't have a formal definition of classes in the programming language per say, it has functions, variables and objects (yes, objects, even if it does not have classes). Basically your JavaScript acts as part of your controller and should call PHP functions to carry out requests on the server. Remember OOP usually takes the MVC (Model View Controller) methodology.
So this code should fire when a message is received from an action. Pass the information to the PHP on the server and the PHP should save the information (as a JSON file or in a SQL database for example).

It's important to note that "object-oriented programming" doesn't necessarily mean "class-based programming", so looking online for "how to write a class in JavaScript" will lead you up a blind alley. (JavaScript instead implements prototype-based programming which should be viewed as a different way to do OOP.)
In a lot of the simple cases you'll have in client-side scripts, you don't need to worry about inheritance, you just want to expose an object which has public methods and private state. So instead of diving right into prototypal inheritance (which takes a bit of getting used to), start by learning how to implement encapsulation, and privately scoped variables.
Here's a succinct introduction to basic public and private members, and below (and in this demo) is a quick abstract example of encapsulation (but no inheritance) using JavaScript's object model:
var my_object = function(start_value) {
/* private variables */
var some_number;
/* private methods */
function garble() {
some_number = 42;
}
/* public methods and properties */
var inst = {
'set_number': function(new_value) {
if ( new_value < 0 ) {
garble();
}
else {
some_number = new_value;
}
},
'get_number': function() {
return some_number;
},
'increment_number': function() {
some_number++;
}
}
// Initialisation
inst.set_number(start_value);
return inst;
}
var foo = new my_object(1);
foo.increment_number();
var bar = new my_object(-20);
bar.increment_number();
document.getElementById('foo').innerHTML = foo.get_number();
document.getElementById('bar').innerHTML = bar.get_number();
Note: I'm not an expert on JS OOP, and there may be gotchas or bad practices in my example above; if anyone more experienced spots one, please let me know in a comment.

Handling API design and OO sugar

Introductory reading:
Prototypes as "classes"
OO JS
Following the patterns described above I create libraries/APIs as the following
var Proto = {
constructor: function () {
this.works = true;
},
method: function () {
return this.works;
}
};
Now for library users to interact with my prototypes (which do not supply factory functions) they have to instantiate and initialize the object
// instantiate
var p = Object.create(Proto);
// initialize
p.constructor();
This is an unfriendly and verbose way of forcing users to instantiate and initialize my objects.
personally since I use pd in all my applications I have the following sugar
// instantiate or initialize
var p = Proto.new();
// or without bolting onto Object.prototype
var p = pd.new(Proto);
However I think it's unkind to force pd onto users so I'm not sure what's the best way to make my libraries usable.
People create new instances of Proto and call .constructor themself
Force people to use pd
Give .create style factory functions
Give up and use new <Function> and .prototype
1 and 2 have already been mentioned.
3 would basically be
Proto.create = pd.new.bind(pd, Proto);
4 would make me sad but confirming to a known standard way of doing things increases usability.
Generally when using non-standard OO patterns what are the easiest mechanisms to allow people to use my library in their application?
I'm currently tempted to say
// here is my Prototype
Proto;
// here is how you instantiate a new instance
var p = Object.create(Proto);
// here is how you initialize it
// yes instantiation and initialization are seperate and should be.
p.constructor();
// Want sugar, use pd.new

For now, you probably make it easiest on your library clients if you use a small API that helps you with building a traditional constructor function, using syntax that looks almost like prototypes-as-classes. Example API usage:
// Superclass
var Person = Class.extend({
constructor: function (name) {
this.name = name;
},
describe: function() {
return "Person called "+this.name;
}
});
// Subclass
var Worker = Person.extend({
constructor: function (name, title) {
Worker.super.constructor.call(this, name);
this.title = title;
},
describe: function () {
return Worker.super.describe.call(this)+" ("+this.title+")";
}
});
var jane = new Worker("Jane", "CTO");
Implementations:
Simple JavaScript Inheritance
I’ve reimplemented Resig’s API, in a way that is possibly easier to understand: rauschma/class-js

I think the way to go is providing the new(Prototype, [arguments]) function as per the "use pd" option. It should even not be that bad from a dependency point of view (since you could have packaged this function separately anyway and is has just a couple of lines of code)
Offering a special function also fits in a sort of historic perspective. If you go way back to Smalltalk or even in more recent cases like Python you have separate functions for object creation (new) and initialization (init, the constructor) and the only only reason we don't notice the separation is because they provide syntactic sugar for object instantiation.

Object-Oriented JavaScript tools

I have been working on the user interface of my website (www.swalif.com: do use chrome to translate if you like to). Not being familiar with jQuery I started off with JavaScript and now the file is huge: about 1000 lines of code. Furthermore the code is getting complex to handle and change.
Therefore I was looking for a way I could approach this problem in an object oriented manner that would result in a clean, re-usable system with a good architecture. Also would be nice to use features as provided by JQuery to keep the code small.
The problem is that there are a lot of tools out there and I cannot decide which one to invest time into to accomplish this task. e.g. mootools, prototype, jQuery, etc. So I need someone to lead me in the right direction.
This is our website www.swalif.com. Any other suggestion are also welcome.

For object-oriented javascript development I would recommend John Resig's Simple javascript Inheritance. It is a tiny bit of javascript that allows you to define classes, derive from base classes and override methods.
var Person = Class.extend({
init: function(isDancing){
this.dancing = isDancing;
},
dance: function(){
return this.dancing;
}
});
var Ninja = Person.extend({
init: function(){
this._super( false );
},
dance: function(){
// Call the inherited version of dance()
return this._super();
},
swingSword: function(){
return true;
}
});
var p = new Person(true);
p.dance(); // => true
var n = new Ninja();
n.dance(); // => false
n.swingSword(); // => true
// Should all be true
p instanceof Person && p instanceof Class &&
n instanceof Ninja && n instanceof Person && n instanceof Class

I think you'd be better off with a framework that actively developed and is build with OOP with extendability, reusability, mixings, mutators in mind.
This is exactly why MooTools was created.
That said, if you're not familiar with JS, it would be pretty difficult to grasp MooTools, since it's not a framework for beginners. Then again, if you grasp the notion of OOP, you should be ok.

Don't actually use a framework to implement your OOP. You get a much richer understanding of Javascript as a language when you deal with the nitty gritty of using Javascript's very flexible function prototype system to implement OOP-like operations.
Read about it here: http://phrogz.net/JS/Classes/OOPinJS.html.

If you only need to organize your code and don't need libraries you may use http://code.google.com/p/joose-js/. Otherwise use the oop model of the library you are using.
Simple example
Module("Test", function (m) {
Class("Point", {
has: {
x: {
is: "rw",
init: 0
},
y: {
is: "rw",
init: 0
}
},
methods: {
clear: function () {
this.setX(0);
this.setY(0);
}
}
})
})

jQuery plugin design pattern (common practice?) for dealing with private functions [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've been developing jQuery plugins for quite some time now, and I like to think I know how to design one well by now. One issue keeps nagging me though, and that is how to deal with private functions in a powerful yet elegant manner.
My plugins generally look something like this:
(function($) {
$.fn.myplugin = function(...) {
...
// some shared functionality, for example:
this.css('background-color', 'green');
...
};
$.fn.mypluginAnotherPublicMethod = function(...) {
...
// some shared functionality, for example:
this.css('background-color', 'red');
...
};
}(jQuery));
Now my question is: how to neatly DRY up that shared functionality? An obvious solution would be to put it in a function within the plugin's namespace:
var fill = function($obj, color) {
$obj.css('background-color', color);
};
Although this solution is effective and nicely namespaced, I really dislike it. For one simple reason: I have to pass it the jQuery object. I.e. I have to call it like this: fill(this, 'red');, while I would like to call it like this: this.fill('red');
Of course we could achieve this result by simply putting fill into jQuery.fn. But that feels very uncomfortable. Imagine having ten plugins developed based on this approach and each plugin putting five of those 'private' functions into the jQuery function namespace. It ends up in a big mess. We could mitigate by prefixing each of these functions with the name of the plugin they belong to, but that doesn't really make it more attractive. These functions are supposed to be private to the plugin, so we do not want to expose them to the outside world at all (at least not directly).
So there's my question: does anyone of you have suggestions for how to get the best of both worlds. That is; plugin code being able to call 'private' plugin functions in a way similar to this.fill('red') (or this.myplugin.fill('red') or even this.myplugin().fill('red') etc.), while preventing jQuery function namespace pollution. And of course it should be light-weight, as these private functions might be called very frequently.
UPDATE: Thanks for your suggestions.
I especially like David's idea of defining an object type that holds the 'private' functions and wraps a jQuery object. The only problem with it is that it still disallows me from chaining 'private' and 'public' functions. Which was big reason to want a syntax like this.fill('red') to begin with.
I ended up with a solution which I consider not tremendously elegant, but appealing to the 'best of both worlds' cause:
$.fn.chain = function(func) {
return func.apply(this, Array.prototype.slice.call(arguments, 1));
};
Which allows for constructs like:
this.
find('.acertainclass').
chain(fill, 'red').
click(function() {
alert("I'm red");
});
I cross-posted my question in other places, which also collected some interesting responses:
http://forum.jquery.com/topic/jquery-plugin-design-pattern-common-practice-for-dealing-with-private-functions
http://groups.google.com/group/jquery-en/browse_thread/thread/fa8ccef21ccc589a

One thing first: if you would like to call something like this.fill('red'); where this is an instance of jQuery, you have to extend the jQuery prototype and make fill() "public". jQuery provides guidelines for extending it's prototype using so called "plugins" that can be added using $.fn.fill, which is the same as jQuery.prototype.fill.
In jQuery callbacks, this is often a reference to the HTML Element, and you can't add prototypes to those (yet). That is one of the reason why jQuery wraps elements and return jQuery instances that can be easily extended.
Using the (function(){})(); syntax, you can create and execute "private" javascript on the fly, and it all disappears when it's done. Using this technique, you can create your own jQuery-like syntax that wraps jQuery into your own private chainable object.
(function(){
var P = function(elem) {
return new Private(elem);
};
var Private = function(elem) {
this.elem = jQuery(elem);
}
Private.prototype = {
elem: null,
fill: function(col) {
this.elem.css('background',col);
return this;
},
color: function(col) {
this.elem.css('color', col);
return this;
}
}
$.fn.myplugin = function() {
P(this).fill('red');
};
$.fn.myotherplugin = function() {
P(this).fill('yellow').color('green');
};
})();
$('.foo').myplugin();
$('.bar').myotherplugin();
console.log(typeof P === 'undefined') // should print 'true'
This way, the P stands for your own toolbox of "private" functions. They won't be available anywhere else in the code or in the jQuery namespace unless you attach them somewhere. You can add as many methods as you like in the Private object, and as long as you return this, you can also chain them jQuery-style as I did in the example.

How about (within the plugin's scope):
var fill = function ()
{
(function (color)
{
this.css ('backgrorund-color', color);
//.. your stuff here ...
}).apply (this, arguments);
}
$.fn.myplugin = function ()
{
fill ('green');
}
That way, fill will retain the jQuery context you're in, and is still private to your plugin
Amended: the above is incorrect w.r.t. scoping, Try the following instead:
var fill = function (color)
{
if (!$this) return; // break if not within correct context
$this.css ('backgrorund-color', color);
//.. your stuff here ...
}
$.fn.myplugin = function ()
{
var $this = $(this); // local ref to current context
fill ('green');
}

You might want to take a look at how the jQuery UI Widget Factory is implemented.
The basic approach is like this:
(function($){
$.fn.myplugin = function(method)
{
if (mp[method]) // map $('foo').myplugin('bar', 'baz') to mp.bar('baz')
{
return mp[method].apply(this, Array.prototype.slice.call(arguments, 1));
}
else if (typeof method === 'object' || ! method)
{
return mp.init.apply(this, arguments); // if called without arguments, init
}
else
{
$.error('Method ' + method + ' does not exist on $.myplugin');
}
};
// private methods, internally accessible via this.foo, this.bar
var foo = function() { … };
var bar = function() { … };
var private = { // alternative approach to private methods, accessible via this.private.foo
foo : function() { … },
bar : function() { … }
}
var mp = { // public methods, externally accessible via $.myplugin('foo', 'bar')
init : function( options )
{
return this.each(function()
{
// do init stuff
}
},
foo : function() { … },
bar : function() { … }
};
})(jQuery);

Unfortunately, "private" methods (or any property for that matter) can never be called with a "this" prefix in javascript. Anything which is called like this.myFunc(myArgs) must be publicly available.
And "private" methods can only be called from within the scope in which they were defined.
Your original solution is the only one that will work. Yes, it's a pain having to pass in this, but there's no more verbosity than there would be if your impossible request was possible:
this.fill('green');
//or
fill(this,'green');
As you can see, they both take up exactly the same number of characters in your code.
Sorry to say, but you're stuck with this as a solution, unless you want to create a new namespace and make them not private - which is simply going to add to the amount of code you need to write, i.e. what you indirectly called "not directly exposed":
this.myplugin.fill('green');
...is more verbose, thus kind of defeats the purpose.
Javascript is not like other languages, there are no "private" members per-se, only members accessible within closures, which can sometimes be used in a similar way to private members, but is more of a "workaround", and not the "real-deal" private members you are looking for.
It can be difficult to come to terms with this (I often struggle), but don't try to mould javascript into what you understand from other languages, take it for what it is...