Wow I am incredibly impressed by this, great work to the DocumentCloud team! I can't wait to throw this into real-life use... it looks like everything I could ever want in a framework.
I too am a jQuery developer, but not your typical one. I tend to avoid slapping plugins together and write most of my own things from scratch, in my own pythonic classical style. I also tend to use the little jQuery helper methods and CSS selector tools purely as an interface to the DOM. The hard work is all done via classes, which drastically reduces the code that I write. I see other not-so-skilled jQuery script kiddies out there piecing together documents full of $('#blah') this and $('#bloo') that with little regard for chaining or simplifying things. I digress, as that is not the demographic for this wonderful library of code.
Here is an example of what kind of code I have been writing as of late: http://dpaste.de/pKOi/ -- as you can see, there is a small bit if boilerplate required and a 'var self = this' inside of each class method that is required. That's more for my own personal style actually, to help with preventing loss of 'this' scope down the road. Anyway... over time this code just sort of piles up and it would be nicer to 1) have a better way to define and organize it all, and 2) all of the great model/collection/validation stuff looks excellent! Evented programming is brilliant to, and the fact that a thousand pieces of code can all stay in sync thru events is just fantastic.
I'm a JavaScript newbie. I'm just curious as to how your code (as shown in dpaste.de/pKOi) is better than Douglas Crrockford's module pattern? Please enlighten me,thanks for help.
Basically he’s just using JavaScript’s built-in objects and making the initializer function call the prototype's init. The advantage vs. Crockford’s "module pattern" is that if you plan to make many instances, the functions don’t all need to be recompiled every time, or take up extra memory.
I would advise the GP poster to pick up some class implementation (or roll his own), and use some bind function instead of all the `self`s (if only because other JavaScript programmers will recognize the style better). One that seems to work reasonably well for simple use cases is John Resig’s suggestion, http://ejohn.org/blog/simple-javascript-inheritance/ though one thing to keep in mind with that implementation (just as with the poster's) is that new instances must be created with `new`.
However you decide to do it, the prerelease versions of Resig’s upcoming book are quite helpful in understanding how these designs work and all the tricky corners of JavaScript closures and object inheritance.
I too am a jQuery developer, but not your typical one. I tend to avoid slapping plugins together and write most of my own things from scratch, in my own pythonic classical style. I also tend to use the little jQuery helper methods and CSS selector tools purely as an interface to the DOM. The hard work is all done via classes, which drastically reduces the code that I write. I see other not-so-skilled jQuery script kiddies out there piecing together documents full of $('#blah') this and $('#bloo') that with little regard for chaining or simplifying things. I digress, as that is not the demographic for this wonderful library of code.
Here is an example of what kind of code I have been writing as of late: http://dpaste.de/pKOi/ -- as you can see, there is a small bit if boilerplate required and a 'var self = this' inside of each class method that is required. That's more for my own personal style actually, to help with preventing loss of 'this' scope down the road. Anyway... over time this code just sort of piles up and it would be nicer to 1) have a better way to define and organize it all, and 2) all of the great model/collection/validation stuff looks excellent! Evented programming is brilliant to, and the fact that a thousand pieces of code can all stay in sync thru events is just fantastic.