hgs yükleme
My Cart (0)  |  My Orders  |  My Downloads  |  My Auction  |  My Account  |  Help

Login |Register        Search

Skin object to include jquery,jquery ui and css in dnn

                Print      Add To Favorite     Add To Watch List     Contact Author

Creator: host   6/4/2012 3:25:11 AM    Author: Bruce Chapman   Source: http://www.ifinity.com.au/2012/01/05/New_Skin_Objects_for_including_jQuery__Javascript_and_CSS_Stylesheets_in_DotNetNuke_Skins   Views: 8008    0    1  
Jquery dnn skin Dnn Skinning Skin Object

    This blog post brings together two threads of thought that I have been thinking about.   The first is related to my recent blog post Implementing jQuery and Javascript Libraries across DotNetNuke versions, and the second was a conversation with Scott Willhite at DotNetNuke World, who asked me why I hadn’t actually ever published anything in the DotNetNuke Forge despite writing lots of stuff.  I didn’t really have a satisfactory answer that didn’t involve using an excuse of inertia or procrastination.

My prior post on jQuery and Javascript implementation has been pretty widely read, and one of the comments on twitter was thus:

So as two things lead to one, I decided to create a set of skin objects that would incorporate the work on jQuery and Javascript libraries into re-usable skin objects and create that as a DotNetNuke forge project.

I already had an older freebie project called iFinity SkinObjects but most of the innovations in that have now been adopted in the DotNetNuke core (nofollow on privacy/terms links, correct home page Url on the Logo, etc).  The SkinObjects project was also written in VB which was now out-of-step with the DotNetNuke core.

So what I did was create an entirely new project, which I called DotNetNuke.SkinObjectsEx, or ‘Extra Skin Objects’ if you want the friendly name.

This has been created as a DotNetNuke Forge project, which has it’s associated Codeplex Project page.  You can download the install package, example skin and Source code from these locations.

What’s in the box?

The SkinObjectsEx project contains 4 separate skin objects to use within your DotNetNuke skins.  It comes in an installable DotNetNuke Extension Zip package which is installed as normal.


The script object allows you to link a javascript file into your skin in a way that is safe for all DotNetNuke versions, and in a way that will leverage the increasing client-site functionality that has been gradually appearing since DotNetNuke 5.0 came out.

The Script object is also a simple way to ensure that both jQuery and jQuery UI are registered on the page in a DotNetNuke-safe way.  I have seen many, many errors created on sites due to hard-coded jQuery or jQuery UI references into a skin, which then cause problems when new modules or DotNetNuke upgrades are introduced.  This saves the skin author having to devolve into code-behind code, when they can just include a simple reference and be certain the correct version of jQuery is going to be registered on the site.


The Stylesheet object is modelled on the standard DNN Styles object, but again brings in the compatibility with the DotNetNuke Client Resource Management framework in order to combine stylesheets for faster performance – in a way that works with all DotNetNuke versions.   In addition, the Stylesheet skin object introduces the ability to link CSS files only for specific DNN versions.  This is done in a from/to pattern, so that you can have one CSS File included up until, say, version 5.6, and another CSS File included from, say, 6.0.   This power allows a skin author to tailor different approaches to different DNN versions, which is very important with the introduction of jQuery UI in DNN 6, which brought a lot of standard CSS definitions with it.


The PageLink skin object provides a simple way to create a link to a specific page in your DotNetNuke site.  While this sounds very simple, in reality skins are often developed away from the intended site, and hard-coding a Url into the skin creates a brittle implementation that is easy to break, and is usually done in a way that doesn’t leverage the proper DotNetNuke Friendly Url API accessed through the NavigateUrl() call.

Portal Date

This is an old one from the original Skin Objects project, and provides a simple way to add the current date or time to every page in the site.  The most important part of this is that it loads up the localised portal date/time, rather than the date/time of the server which it is running on.  For people who have their site hosted in a different timezone to their intended hosting locality, it’s a neat little way to make things look right.

In addition to the above objects, the CodePlex downloads include a variation of the DotNetNuke 6 ‘DarkKnight’ skin, which includes implementation of all of the above skin objects in an example.

This blog post will focus on the Script and Stylesheet skin objects from this point on. 

Using the Script Object

Adding the Skin Object to a DNN Skin is done like this:

First, you register the skin object in the skin:

<%@ Register TagPrefix="dnn" TagName="SCRIPT" Src="~/DesktopModules/SkinObjectsEx/Script.ascx" %>

Then, for each Script library you want referenced on the generated page, you add a new Skin object:

<dnn:SCRIPT id="jquery" ScriptType="jQuery" runat="server" />
<dnn:SCRIPT id="jqueryUI" ScriptType="jQueryUI" runat="server" />
<dnn:SCRIPT id="cycle" ScriptType="other" Path="skin" Location="jquery.cycle.min.js" name="jquery_cycle" InHeader="false" Order="e_Default"  runat="server"/>
<dnn:SCRIPT id="hoverintent" ScriptType="other" Path="relative" location="~/Resources/Shared/Scripts/jquery/jquery.hoverIntent.min.js" name="hoverintent" Order="e_Default" runat="server" />

The above example shows 4 different Scripts to be included on the output page.  The first is a request for the jQuery library.  The second is a request for the jQuery UI library.  The last two are references to the ‘jquery.cycle.min.js’ and ‘jquery.hoverintent.min.js’ libraries which are referenced in the ‘DarkKnight’ skin. 

The final two references replace this in the standard DNN 6 DarkKnight skin:

<script type="text/javascript" src="<%=SkinPath %>jquery.cycle.min.js"></script>
<script runat="server">
  'for mega menu we need to register hoverIntent plugin, but avoid duplicate registrations
  Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Page.ClientScript.RegisterClientScriptInclude("hoverintent", ResolveUrl("~/Resources/Shared/Scripts/jquery/jquery.hoverIntent.min.js"))
  End Sub

There are 6 different properties in the Script object, all of which combine to control the behaviour of the way the final script is linked on the output page.

The properties are:


ScriptType controls the type of script the skin object uses.  There are three choices: ‘jQuery’, ‘jQueryUI’,’other’.  The first two should be obvious – they just include a reference to the jQuery and jQueryUI libraries accordingly.  The ‘other’ is anything else, apart from jQuery.  You don’t need to include this value for ‘other’ types, as ‘other’  is the default.

Looking back at the prior example, you can see how the ScriptType is used in the 4 different examples.


Path is also a value with set values.  These are ‘Skin’, ‘Absolute’ and ‘Relative’.  When using a path type of ‘Skin’, the library is referenced from the installed skin path.  When using a path type of ‘Absolute’, the library is reference from the absolute location specified.  When using ‘Relative’, the location is specified with a tilde (~) and is passed into the ‘ResolveUrl’ function to create a fully qualified path.   In the above examples, you can see how the ‘hoverintent.js’ skin object replaces the included ‘code behind’ in the skin files.


Location is the component that combines with the ‘Path’ value to create the fully reference Url.   For Path=”Skin” location is just the relative path in the Skin directory (ie, where the skin is installed).   For Path=”Absolute”, Location is the fully qualified Url to the file.  For ‘Relative’, location is the relative Url that ASP.NET will resolve at runtime.


Name is just a unique identifier that ensures that the script is not added twice in the one page.


Order is used for DNN 6.1+ installations, and determines where in the list of resources the item is inserted.  These values come from the earlier work done in the jQuery and Javascript Libraries in DotNetNuke post already referenced. 

The values for Order are:

a_BeforejQuery, b_BeforeDnnXml, c_BeforeDomPositioning, d_BeforeDnnControls, e_Default

The alphabetic prefix just helps with understanding the overall order of things.  This allows you to control where in the hierarchy of scripts your linked script will appear.


This is a boolean value which controls whether or not to include the header within the <head> section of the Html, or whether to include it in the <body> section.  In some cases, this will be overridden by the logic contained within the code, to prevent quirks for individual DNN Versions from breaking your javascript.  These are always moving from <head> to <body>, and only apply to the jQuery and jQuery UI usage.


The StyleSheet skin object uses a similar approach to the Script object in that it uses the same logic to seamlessly integrate regardless of the installed DotNetNuke version.

Here’s a reference as shown in the example DarkKnight skin:

<%@ Register TagPrefix="dnn" TagName="STYLESHEET" Src="~/DesktopModules/SkinObjectsEx/StyleSheet.ascx" %>

and the skin object usage:

<dnn:STYLESHEET runat="server" id="StylesIE7Ex" Name="IE7MinusEx" path="skin" location="ie7skin.css" Condition="LT IE 8" Order="c_BeforeSkin" InHeader="true" />

Note that this replaces the DNN STYLES reference in the DNN 6 DarkKnight skin:

<dnn:STYLES runat="server" ID="StylesIE7" Name="IE7Minus" StyleSheet="ie7skin.css" Condition="LT IE 8" UseSkinPath="true"/>

On first glance these would appear to be the same, and they largely are (the STYLESHEET object is a fork of the STYLES code).   However, the StyleSheet skin object has some big advantages:
- it will utilise the DotNetNuke Client Resource Management (aka imbibe) framework to combine all stylesheets into a single downloadable file, if it is available

- it allows you to specify FromVersion and ToVersion properties which controls whether or not to include the stylesheet with a particular version or range of DNN versions.  This allows the skin author to have a single installable skin that has a different stylesheet for, say, DNN 6 and DNN 5.

Here are the properties for the StyleSheet object:

Carried over from the Styles object, the condition allows you to add a CSS Condition which helps to determine usage for particular browsers


This property is carried over from the Styles object, and allows you to specify the media attribute for the stylesheet.


The Name property uniquely identifies a stylesheet so that a single version is implemented per page


The Path location works the same as the Script object, in that it has a choice of Absolute/Relative and Skin.  This controls the references of the Location property.


As with the Script object, the Location is used to combine with the Path value, and determine the actual Url of the stylesheet.  See the Script definition for ‘Location’ above for more information.


As with the Script object, the Order path allows you to specify a particular insertion order for a stylesheet.  Note this value only works for DNN 6.1+ versions, and is ignored in prior DNN versions (in these cases, order is determined by the execution order, ie, the location on the skin file).   The values for order are:

a_BeforeDefault, b_BeforeModule, c_BeforeSkin, d_BeforeContainer, e_BeforePortal, f_Last

These are entered as a string property value, which then converts them to a numeric value.

FromVersion / ToVersion

These two properties allow you to specify from and to DNN Versions.  If the currently executing DNN version falls greater than or equal to the FromVersion value, and less than or equal to the ToVersion value, the file will be included.   You do not need both, but can specify both.  So you can have a ‘FromVersion=”6.0"’ to always include the CSS File from Version 6, or you can have ‘FromVersion=”5.5” ToVersion=”5.7” to only use the file in versions 5.5, 5.6 and 5.7 (although 5.7 doesn’t exist).  And you can have a single version like ‘ToVersion=”5.4”’ to include the file up to the 5.4 version.

The format allows you to specify any level of detail, so you can say ‘FromVersion=”6”’ which is just the major build version, or you can qualify to the minor version (“6.1”) or down to the revision value (“6.1.1”).  The system will automatically take the value down to the lowest value for any part of the version that isn’t supplied.  So “6” is represented as “6.0.0” and “6.1” is represented as “6.1.0”.

That’s all there is to it!  As the entire component is built without the usual iFinity branding I include, and is distributed under the same free licence as DotNetNuke, any skin developers can integrate these features into not only custom skins for particular clients, or into distributable skins they sell on Snowcovered or elsewhere.

Frequently Asked Questions

I’m guessing at some questions here as I haven’t really spoken to anyone about this, but here goes:

Why wouldn’t I just use the DnnJsInclude and DnnCssInclude skin objects in DNN 6.1?

These are the future path for everyone targeting 6.1+ DNN releases, and work well and are fully integrated into the Imbibe framework.  However, in the messy real world of DNN installs, not everyone is up to date on the latest release, and building a skin to suit both current installs and future DNN 6 upgrades is tricky.  The approach in this project gives the best of both worlds : simple JS and CSS inclusion now, and a seamless future upgrade path for when the client finally brings their install up to date in DNN 6.

It also suits those who want to sell/distribute a DNN 6.1 compatible skin now, but not close themselves off to those who are still running DNN 5. 

Why would you include a Script object of ScriptType=”jQuery” – even in DNN 5, this was included?

It’s true that DNN5 shipped with jQuery, however, it’s possible that a specific page doesn’t have the jQuery library referenced.  This is because the DNN code – somewhere in the page execution – has to call the jQuery registration code.   The Script skin object with ‘ScriptType=”jQuery”’ will guarantee to the skin developer that jQuery is reference on the output page, no matter what the installed DNN version is.  That way no skin developer should ever have to include the jQuery library themselves.  

The same goes for the jQuery UI library – which is included in DNN 6 but not DNN 5.  By including a ‘ScriptType=”jQueryUI”’ Script skin object, you can be sure of a reference to jQuery UI being included on your output page, no matter if it is DNN5 or DNN6, and you can be guaranteed not to have a duplicate jQuery UI reference in DNN 6.

What about DNN 4?  Is this compatible?

The project is compiled against DNN 5.1.2 so can’t be used on earlier versions.  You shouldn’t be doing DNN 4 stuff, really, it’s way out of date.  However, if the powers-that-be control your DNN life and DNN 4 is it, you can probably change the reference and recompile to a DNN 4 version. It should still work OK.

Why would I want different CSS references for different DNN Versions

The inclusion of jQuery UI and the extensive use (and redefinition) of jQuery UI components (like the jQuery UI Tabs CSS classes) means that, for example, a CSS Class built for a DNN 5 skin might not layout properly when installed on a DNN 6 install.  A skin designer wishing to make a cross-version compatible skin can use this component to run slightly different CSS files for 5 and 6, and their clients won’t know the difference – and perhaps most importantly – won’t ring them in the middle of the night after upgrading their DNN install and finding their layout all broken (or is it just me that doesn’t share a timezone with anyone else in the world)

What’s with this ‘Imbibe’ stuff?

This is my little personal crusade towards better project naming.  I mean ‘DotNetNuke Client Resource Management Framework’ – that’s a mouthful of syllables, and distinctly Acronym-challenged (DCRMF?).  So I called it Imbibe and hope it catches on.  It won’t, of course, but if anyone ever comes up to me one day and goes ‘I’ve got a question about Imbibe for you’ I will give them a little high-five!

Of course, with all those FAQ’s answered, please feel free to hit me up with more questions in the comments below, or in the CodePlex project.  This is my first Forge project released into the wild, so please give valuable feedback to get it up and running and living an independent life in the DNN ecosystem.

Rating People: 29   Average Rating:     

     DnnModule.com is built to provide DNN quality modules and DNN skins, some of them are free, some not. We wish these stuffs (free or not ) can be useful to you.

     Besides that, we also provide a full range of professional services, ranging from web site build, seo, system management, administration, support, senior consultancy and security services. We act as if your development project or network was ours, with care and respect. We are not satisfied until it works the way you want it to, and we don't silently ignore found issues as somebody else's problem.