Contents tagged with jQuery
-
JavaScript: Global Variables
One of the biggest issues that you can run into with writing JavaScript is abusing the shared global namespace, and overwriting the variables of an unrelated script. Everything that you declare in JavaScript is available to every other script on the page, unless you wrap the declaration in a function. Also, if you use a variable without declaring it (even within a function), it will be declared for you in the global scope.
There are a couple of remedies we have against creating a global soup of conflicting variables. Knowing is half the battle, so step one is just keeping an eye out. Recognize when you’re creating a function or variable, and make sure that it’s not a global. The main technique for this is to declare everything inside a function. If you’re writing jQuery scripts, most of your script is probably being written inside the callback passed to
jQuery(document).ready(), so you’re mostly safe already. If you’re not using a function already, you can wrap your code in an immediately invoked function expression.Step two is to catch when you miss declaring a variable. There are two ways to do this. The first is to turn on strict mode, so that browsers which support strict mode will throw an error when you try to access an undefined variable (instead of defining it as a global). In addition, you should be running your code through a linter (JSLint or JSHint) to catch issues like this.
So, now that you know how not to expose global variable, what about if you need to? If you need to write code in one script and reference it from another, you’ll need to expose a reference to that code somehow, right?
In this case, you should still probably be using all of the above techniques to keep the scope clean, but then explicitly expose anything that you need to. Again, if you’re using jQuery, this is fairly natural. Your script will take a reference to the global jQuery function, and you can add your script as a plugin to
jQuery.fn. If you’re not exposing a jQuery plugin, you can take a reference to the globalwindowobject, and add your object explicitly. As an example:(function (window, $) { “use strict”; // turn on strict mode var x = 10; // x will not be accessible outside of this function y = x * 20; // y will be declared as a global variable, unless the browser supports strict mode $.fn.myPlugin = function (args) { ... }; // expose your plugin to the rest of the page window.textbox2_validate = function (sender, args) { ... }; // expose a standard function }(this, jQuery)) // immediately invoke this function expression, passing in this (a reference to the global scope) and jQuery -
JavaScript: The Language
I gave my JavaScript language talk at the St. Louis .NET/DotNetNuke User Group last night. I’ve posted the presentation (with some updated, clarified example code) up on slideshare.
I woke up this morning thinking through all of the things that I could have explained better and how to more succinctly get the important points across. So, I’m now declaring (so that you, my loyal readership, can hold me to it) that I’m going to do a series on this blog focusing on illuminating common difficulties and misconceptions in JavaScript. Look forward to a discussion of closure sometime this week.
-
Chicago Day Of DotNetNuke 2010 Recap
Saturday, October 2nd was the Day of DotNetNuke in Chicago. A number of us from Engage attended and spoke. I gave two presentations, which are now available on SlideShare (linked below). I’ve added some notes (be sure to click the “Notes on slide 1” tab when viewing on SlideShare) to give context if you weren’t able to attend the session.
Considerations with Writing JavaScript in your DotNetNuke® site Overall, we definitely were glad to participate in the event. The logistics were pulled off excellently (you certainly couldn’t tell that none of the organizers had organized an event of this magnitude before). I was also great to see the number of community leaders that were presenting and available. It really was a treasure-trove of DNN knowledge.
Nik Kalyani, the keynote speaker, did a great job of emphasizing the role that the community needs to play in guiding the development of DNN. A lot of us walked away excited about what we could contribute to move the community and platform forward.
Nik introduced the concept of a DNN Meme. This is an idea about DNN that catches on with the community in a way that it cannot be ignored. The basic idea is that if an idea is too good to resist, we need to share it so that something actually happens with it. Nik suggested that we use the hashtag #dnnmeme on twitter, and post bigger ideas to dnnmeme.com (via emailing post@dnnmeme.posterous.com). I’m not sure that the “DNN Meme” name is going to take off, but I can definitely get behind getting our ideas out there, gauging community interest, and pursuing the things that we all know that DNN needs.
In Nik’s session at the end of the day, we discussed a couple of things (documented on dnnmeme.com). The biggest of which was the need for module developers to get together and see where we can come to some agreements on how to implement our modules (whether that be a more standard set of markup/CSS, new features in the DNN core, or an agreement on how to implement large amounts of settings). Based on that discussion, Will Morgenweck created the DotNetNuke Module Standards project on CodePlex, where we can start the discussion of standardizing our approaches to modules.
If you are a module developer, we’d love your input on the patterns that you use when developing modules. Specifically, where you find yourself working around what the core provides, or find that the core doesn’t provide anything to support what you’re doing. We’ve gotten the discussion started with what we do and would like to do, but we need more voices so that we can come up with some real consensus on how to reconcile our different approaches.
