Considerations with Writing JavaScript in your DotNetNuke site
•Als ODP, PDF herunterladen•
2 gefällt mir•2,549 views
Whether you want to take advantage of jQuery, ASP.NET AJAX, or just plain JavaScript, come learn the rules and guidelines for taking advantage of JavaScript within your DotNetNuke site. We'll talk through considerations for enhancing your content, skins, and modules, the best ways to include JavaScript behaviors, and some ways to avoid inconsistencies and frustration.
![[object Object],[object Object]](https://image.slidesharecdn.com/considerationswithwritingjavascriptinyourdotnetnukersite-101009150313-phpapp02/85/Considerations-with-Writing-JavaScript-in-your-DotNetNuke-site-1-320.jpg)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Considerations with Writing JavaScript in your DotNetNuke site
Ähnlich wie Considerations with Writing JavaScript in your DotNetNuke site (20)
Mehr von Engage Software
Mehr von Engage Software (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Considerations with Writing JavaScript in your DotNetNuke site
Hinweis der Redaktion
- Whether you want to take advantage of jQuery, ASP.NET AJAX, or just plain JavaScript, come learn the rules and guidelines for taking advantage of JavaScript within your DotNetNuke site. We'll talk through considerations for enhancing your content, skins, and modules, the best ways to include JavaScript behaviors, and some ways to avoid inconsistencies and frustration.
- While it may be tempting to think that jQuery is just always on the page, that you don't have to think about it, that's not quite the case. The main reason that you see it on the page is that the Enable Skin Widgets option is checked in the Site Settings. If you turn that off jQuery will only be loaded when something requests it. If you're logged in, you may think that it's still there, but that's because the (older) IconBar control panel requests it. Once you logout, jQuery is only on the page if a module on the page requests it. To do that, call DotNetNuke.Framework.jQuery.RequestRegistration() from your module, skin, skin object, etc.
- In the host settings, there are a few options in terms of how jQuery gets included on the page. You can reference the Debug version, if you're a developer (though, in general, I don't think that'll get you much benefit). You can also use a hosted version of jQuery. The two big options for that are the Google CDN and Microsoft's CDN. The benefit of using a CDN is that most people will already have a cached version of the file when they get to your site, so they won't need to have to latency induced by that initial download. For this reason, I recommend the Google CDN, since the Microsoft CDN isn't nearly as widely used. Google also allows you to specify a partial version of the script (meaning, you reference version 1.4 to get the latest version of the 1.4 script). However, because this could serve up different scripts, Google does not instruct the browser to cache the script for a long time using this method. Thus, the main benefit of the CDN is lost if you don't reference a specific version of jQuery, It also hosts some other interesting scripts, though that shouldn't strongly affect your decision to use it or not.
- In DNN 5.0, the DotNetNuke.Framework.jQuery class was introduced to handle requesting jQuery on the page. In DNN 5.2.3, DNN started switching the protocol of a hosted jQuery script from http to https if it was used on a secure page. This works for the Google CDN, but not necessarily for CDNs. In DNN 5.4.2, the reference to jQuery was moved higher in the page, to cause less conflict with scripts that depend on it.
- ASP.NET AJAX is guaranteed to be on the page since DNN 5 (via a ScriptManager control). This enabled UpdatePanels, ASP.NET AJAX Control Toolkit controls (which have been deprecated), as well as just the JavaScript libraries themselves. The main place you might run into needing to use ASP.NET AJAX is when interacting with Telerik controls via the $find method.
- The main difficulty with JavaScript is that it is very easy for one person's code to interfere with another's, via naming collisions. Be careful about your scripts, make sure that you write your scripts inside of a function (providing a scope for any variables you create), consider writing your scripts in separate files, to ensure modularity.
- Run your scripts through JSLint (jslint.com) to catch errors that are easy to slip up on. It is very strict, to help you be careful. Read JavaScript: The Good Parts to get a better understanding of some of the issues it raises. Look at examples of how to write jQuery plugins.,
- Including JavaScript in a <script> tag in your .ascx control is easy, but it also makes it hard to reuse and maintain your code. It's also duplicated for each instance of your module on the page. Using the ClientScriptManager (via Page.ClientScript) manage your script references make it something you don't have to think much about. However, it doesn't handle script order dependencies. If you have multiple scripts that are dependent, consider (1) combining (and minifying) them, (2) using jQuery.getScript to load them dynamically, (3) sending ClientScriptManager.RegisterStartupScript multiple script tags to register at once. Widgets are a way for non-technical end-users to embed JavaScript in content (i.e. HTML module or similar) via an HTML construct, instead of JavaScript. Something to consider... Telerik controls require the name of a function in order to handle client-side events, so this is a case where you can't easily hide your script from other modules, or use a separate script. There are workarounds, but they're not as simple, and not the sort that Telerik gives many examples for.
- The biggest way that you can avoid inconsistencies in your scripts is to always use jQuery when dealing with the DOM. Even when you think something is simple, it's probably not quite as simple are you expect it to be (at least in IE 6, or some other, obscure browser). Jquery's purpose is to handle those inconsistencies, so let it.
- If you're interested in an excellent platform for DNN Q&A, consider committing to being a part of the DotNetNuke Stack Exchange proposal. I honestly believe it will revolutionize how we help each other and get helped when developing, integrating, and maintaining DNN sites.