[Noah emailed me off list with some JavaScript questions, but kindly agreed to let me respond publicly]
Hey Noah, On 10-Sep-08, at 2:21 PM, Noah Botimer wrote: > Hey Colin, > > I figured I'd just ping you rather than scour for outdated stuff > buried in PPTs... > > You mentioned in France that you had a few code patterns that were > awesome ideas for X reason or other. I'm especially keen on picking > up someone else's treatment for packages/"classes" and handling of > "this". Yeah, this material was part of the Fearless JavaScript presentation that Nico, Eli and I gave in Paris. In case you do need to dig into the slides, they're located here in the wiki: http://wiki.fluidproject.org/display/fluid/Fearless+JavaScript+Workshop > I notice you recommend "that" for the persistent self-reference, and > I kind of like it -- I'm not sure if I like it more or less than > "me", but consistency with Fluid code is something I can dig. I'm > also not sure if I even set it up right in my code. I still find > surprises with scoping occasionally (usually because I forgot "var") > and generally distrust my level of JS enlightenment, so a template/ > pattern would be awesome. I do recommend avoiding the slipperiness of the "this" pointer in JavaScript by referring to your own stable reference to the current instance. The specific name doesn't matter to me at all. Call it "me," "self," "foo," or whatever you prefer. The only reason we chose to call it "that" was because it seemed simultaneously funny and obvious. It's also the convention that Douglas Crockford uses, so it has a chance of being recognizable to others. Here's how I set it up: // Creator function instead of a constructor with the new keyword var myCoolThing = function (lots, of, args) { var that = {}; // Stable pointer to the current instance // public methods here. that.publicMethod = function () { doSomething(); } return that; // Don't forget to return your new instance. }; The ability to omit var is really the worst bug in the language, so I can sympathize the kind of scoping accidents. The language should thrown an error in this case, but it doesn't. In order to avoid these kinds of common mistakes, I often use JSLint to scan my code. It fills in all the things I miss about not having a compiler. http://www.jslint.com/ > I also like passing the skeleton object to the constructor by the > same name as within the package -- it feels more explanatory than > the this.whatever = function() syntax. And the insulation of jQuery > vs. $ is a sweet hack. Yeah, the use of an anonymous closure wrapping your code is a really awesome way to ensure you've got your little scope, independent of everyone else's code. And it's a nice way to provide convenient aliases. Here's how we tend to do it: fluid = fluid || {}; // Define the namespace we're part of. // Define an anonymous closure which will serve as our own private space. (function ($) { // Code goes here. fluid.uploader = function () {...}; })(jQuery); We're also planning to use this technique in a future release of Infusion to provide support for multiple simultaneous version of our code. > Do you have some current links to this stuff handy? I have a page in the wiki documenting a few of our recommended techniques, including a little template you can cut and paste: http://wiki.fluidproject.org/display/fluid/How+to+Define+a+Unit But you're reminding me that I should probably document more of the Fearless JavaScript material in the wiki as well. It's something Anastasia and I will work on together for Fluid user manual. I'd also really like to make a little plugin for Aptana/Eclipse for creating new objects. Let me know if this is at all helpful. I'd love feedback or ideas about techniques you'd like to know more about. Or if you're totally confused by it, that's helpful to know too. Or techniques you like to use. :) Colin --- Colin Clark Technical Lead, Fluid Project Adaptive Technology Resource Centre, University of Toronto http://fluidproject.org _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
