Verwendung der Client Resource Management API in einem DotNetNuke Skin

DotNetNuke  bietet ja seit der Version 6.x an das die CSS und JavaScript Resourcen (Dateien) zusammengefasst werden. Auf die Vorteile muss hier nicht im Einzelnen eingegangen werden - nur so viel: Es kann die Ladezeit einer Seite deutlich erhöhen. Bei der Erstellung von einem Skin legt man im Regelfall eine skin.css ein, die dann alle relevanten Formatierungsanweisungen beinhaltet. Wenn man nun externe CSS Dateien noch mit in das Skin einbinden möchte (oder seine eigene Struktur über mehrere Dateien verteilt) wird vielfach der CSS Befehl @Import genutzt. In diesem Fall werden die importierten Dateien nicht berücksichtigt bzw. mit in eine große Datei gepackt.  Damit weitere CSS Dateien (oder auch JS Dateien) berücksichtigt werden, muss man die DotNetNuke SkinObjects DnnCssInclude bzw. DnnJsInclude nutzen. Vor der Nutzung muss man noch die Komponente registrieren in der Skin-Datei, das passiert über den üblichen Weg: <%@ Register TagPrefix="dnn" Namespace="DotNetNuke.Web.Client.ClientResourceManagement" Assembly="DotNetNuke.Web.Client" %> Ein konkretes Beispiel für die Einbindung könnte dann so aussehen: <dnn:DnnCssInclude runat="server" FilePath="menu/menu.css" PathNameAlias="SkinPath" /> Der optionale Parameter PathNameAlias kann mit den Werte SkinPath oder SharedScripts gefüllt werden. SkinPath ist dabei der aktuelle Pfad zum verwendeten Skin und somit lassen sich alle Dateien unterhalb vom Skinverzeichnis einbinden und bei SharedScripts wird das Verzeichnis ~/Resources/Shared/Scripts/ als Basisverzeichnis genutzt.  Zusätzlich kann man noch über die Option Priority die Reihenfolge der Dateien bestimmen. Weitere Informationen findet man dazu auch im offiziellen DotNetNuke Wiki.

Conditional Stylesheets oder CSS hacks

Jeder der sich schon mal mit dem Thema Webdesign beschäftigt hat, kennt die Probleme der unterschiedlichen Browser. Besonders der Internet Explorer ist ein Kandidat, bei dem man sehr schnell graue Haare bekommt kann. Meistens werden Hacks verwendet, die nur von bestimmten Versionen / Browsern erkannt bzw. akzeptiert werden und von den anderen als Fehler ignoriert. Das Problem von solchen Hacks ist unter anderem dafür sorgen das eine CSS nicht mehr validiert werden kann. Um dieses Problem zu umgehen verwenden viele Conditional Stylesheets, die dann vom jeweiligen Browser erkannt und geladen werden. Das sieht dann so aus:<link rel="stylesheet" type="text/css" media="screen" href="skin/css/style.css" /> <!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="skin/css/ie7.css" />< ![endif]--> <!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="skin/css/ie6.css" />< ![endif]-->Nun kann man für die verschiedenen Browser(versionen) die entsprecheden CSS-Definitionen sauber überschreiben. Ist doch super oder?Diese Variante ist schon deutlich besser als die Verwendung von Hacks im eigentlichen CSS aber hat den großen Nachteil das noch mehr Dateien vom Server geladen werden müssen. Eine deutlich besser Lösung sieht so aus:<!--[if lt IE 7 ]> <html class="ie6"> <![endif]--> <!--[if IE 7 ]> <html class="ie7"> <![endif]--> <!--[if IE 8 ]> <html class="ie8"> <![endif]--> <!--[if IE 9 ]> <html class="ie9"> <![endif]--> <!--[if (gt IE 9)|!(IE)]><!--> <html class=""> <!--<![endif]-->Hier wird nun in Abhängigkeit von der Browserversion das Tag HTML mit einer CSS-Klasse versehen und man kann nun ganz sauber und ohne Hacks für die div. Versionen CSS-Definitionen erstellen, dass dann z.B. so aussieht:: div.contentpane { width: 510px; } .ie6 div.contentpane { width: 500px; }Diese Technik wird z.B. auch vom bekannten http://html5boilerplate.com/ verwendet.