OO JQuery and classes

I'm working on a site and using JQuery for essentially the first time. I've mostly used MooTools for previous projects, and I have a few widget classes I've written using the MooTools Class structure. I'd like to port them over to JQuery, but it looks to me like there is nothing similar to the MooTools functionality when it comes to object classes.

I've searched around a bit, and haven't found much on it. Digg appears to have rolled their own, but I'm not sure if this is something I should be using. Is there a better way? How object-oriented do people normally get with JQuery? What's the usual method of encapsulating a UI widget (or any functional class structure)?

I'll post a fake example of a possible MooTools widget class:

var ZombatWidget = new Class({
    Extends: BaseWidget,
    widgetPropertyX = 'prop1',
    widgetPropertyY = 'prop2',
    attach = function(el) {
        var f = function() { 
            //do something widgety
        };
        el.addEvent('dblclick',f);
        el.addClass('widgetized');
    }
});

var z = new ZombatWidget();
z.attach($('widgetDiv'));

What I've got is a lot bigger than that, but you get the idea. Do I need to convert this to the prototype method of class/inheritance structuring? How would you write this kind of object class using JQuery?

Answers


You might find this approach useful to the task at stake: building an object-oriented jquery plugin.

And this article on Ajaxian "a real OO class system with jquery".


Hm... interesting. We have jQuery which imho is a great tool to interact with the DOM. It's a selection tool where you can write your own code (plugins) to modify selected items. You can interact here with your own (object oriented) code in a plugin to do something really cool.

So why would you need extra OO capabilities in jQuery unless you want to be able to inherit from other jQuery plugins?

Because you might have a plugin that allows you to do the following:

$(".spiffyness").yourSpiffyficationPlugin1();

And, while doing some really cool awesomeness already, you need more spiffyness on top of this.

Therefore you want to inherit from your first plugin which results in:

$(".spiffyness").yourSpiffyficationPlugin2(); //plugin inherited from 1

But... wouldn't you get there too by doing this:

$(".spiffyness").yourSpiffyficationPlugin1().yourSpiffyficationPlugin2();

Where the second plugin just does this tiny (but awesome ;)) thing extra on top of the first one?

In other words: is what you want, worth the effort for the sake of OO purism? Or is the jQuery pipe mechanism good enough and maybe everything you need?

I would say that separation of responsibilities and/or your mootools mindset might be the real issue here. Let jQuery do what it is good at, use it's powerfull pipe mechanism, pipe your own plugins (which may contain tons of fancy OO stuff)... and you can have great results while your code is still clean.

If you do think I am thinking too simple here, a good example of the essence of your point would be welcome! :-)

And to be ahead of that, if you are doing something really advanced and you do not get away with simply doing something on top of something else, you're plugin could also delegate to one of your OO classes. E.g. like:

$.fn.totalAwesomeness = function(options) {
  var defaults = {
    mode: 1,
    title: 'Awesome'
  };
  var opts = $.extend(defaults, options);
  return this.each(function() {
    var $this = $(this);
    var handler = null;
    if(defaults.mode == 1)
       handler = new com.myStuff.class1($this);
    else if(defaults.mode == 2)
   handler = new com.myStuff.class2($this); //class2 inherits from class1 
    handler.doMagic();
  });
};

You can always also use moo4q - http://moo4q.com/ . It adds MooTools class support to jQuery.


I wrote an article some time ago about jQuery object oriented plugins, hope it will be helpful

http://ajax911.com/jquery-object-oriented-plugins/


There are third party javascript class implementations that provide very powerful introspection capabilites. I would like to particularly highlight JS.Class and Joose. While JS.Class is modeled after Ruby, Joose is modeled after Moose. I am not a mootools user so I can not comment on their advantages/disadvantages with respect to mootools. But I would summarize their key features.

JS.Class has a strong focus on simulating the Object oriented features of Ruby and does a pretty good job at that. It provides a powerful library modeled after the standard library of Ruby and also comes with a well integrated package management and testing framework.

Joose, while provides no testing framework/package management facilites, excels in terms of advanced attribute management facilities, filters and better introspection facilities.

Both of them have really good documentation and can be used in browser as well as server.


I've just finished a very first release of my mini project: https://github.com/op1ekun/plOOgins. It's all about writing OOP code to be used as Jquery plugins. It's not rocket science just a little something that we wanted to use at my workplace. Maybe it will help You a bit. Good luck!


Plugins sometimes do the trick.

Of course, you could use just enough of mootools to get it's class/inheritance model. With the implementation of document.id "compatibility mode" in 1.2.3 you can have your cake and eat it too (I think--haven't done it myself.)


The question is... Why are you moving away from MooTools is it fits your needs? Seems to me like MooTools was working fine, and there is nothing jQuery does that MooTools can't do. (The opposite isn't true).

Unfortunately, jQuery is not built to support classical OOP as MooTools is so you will need to write your Classes as jQuery plugins.


Need Your Help

Add onClick event to document.createElement("th")

javascript html-table

I am dynamically adding columns to a table by using document.createElement("th")

Gunicorn worker timeout error

gunicorn

I have setup gunicorn with 3 workers 30 worker connections and using eventlet worker class. It is setup behind Nginx. After every few requests, I see this in the logs.