Microsoft SharePoint 2010

Style Library vs. Layouts Folder in Sharepoint 2010

Im aktuellen Sharepoint Projekt kamen wir irgendwann an den Punkt, an dem wir festgestellt haben, dass die von uns entwickelte Branding Solution mit der Style Library einige Probleme verursacht hat.

Während des Projekts haben wir uns daher kurz entschlossen, die Branding relevanten Dateien (also CSS, Layout Bilder und JavaScripts) aus der Style Library in den Layouts-Ordner zu verschieben. Es hat funktioniert (warum sollte es auch nicht), aber ich bin erst hinterher dazu gekommen, mir mal Gedanken zu machen, was für Vor- oder Nachteile oder Auswirkungen das hat.

Ich bin zu dem Entschluss gekommen, dass in meinen Augen das Ablegen der Branding relevanten Dateien im Layouts-Ordner eigentlich sogar der bessere Weg ist.

Die Style Library ist eine ghostable Library, dass heisst alle Dateien werden im Dateisystem vorgehalten und als Kopie in die Datenbank gespeichert. Da sie nicht manuell bearbeitet werden sollen (da wir ja extra eine Solution dafür haben), brauchen wir dieses Feature eigentlich nicht. Eher im Gegenteil. Das Ghosting hat während der Entwicklung und dem Deployment auf dem Live-System dafür gesorgt, dass unsere CSS-Dateien nicht immer aktualisiert wurden, was doch für einige verwunderte Entwicklerblick gesorgt hat, weil sich keiner das Verhalten erklären konnte (in neun von 10 Fällen funktioniert es; nur immer, wenn es wirklich grad wichtig war, nicht…).

Weiterhin muss man sagen, da die Style Library ja virtuell in der Datenbank vorliegt, sind weitaus mehr Layer vorhanden, die die Dateien letztenendes passieren müssen, bis sie vom Webserver ausgeliefert werden (Datenbank, Netzwerk, Objektmodell, Webserver), während der Layouts Ordner ja nur eine 1:1 Repräsentation des Ordners im Dateisystem ist, was aus meiner Sicht den Zugriff ressourcenschonender macht.

Sicherlich hat auch der Layouts-Ordner seine Nachteile, so wird die Style Library in der Content Database vorgehalten und bei einem Backup ebenfalls mitgesichert und auch wiederhergestellt; Farmen, die eine gemeinsame Content-Database nutzen (über Cluster oder auch Single-Server) greifen auf die gleichen Dateien zu. Aber diese Nachteile bzgl. des Backups kamen in unserem Fall sowieso nicht zum tragen. Im Live System war zwar genau der Fall vorhanden, dass mehrere Frontend Webserver auf die gleiche Datenbank zugriffen, allerdings enthielt unsere Branding Solution natürlich auch mehr als lediglich nur ein paar Styles. Ich spreche hier von UserControls, Masterpages, FeatureReceiver, uvm. Das heisst das Branding hätte mittels eines einfachen Datenbank Backups gar nicht wiederhergestellt werden können, da die Solution zwangsweise deployed hätte werden müssen (und somit unsere Style Dateien ebenfalls wieder vorhanden gewesen wären).

Dazu kommt, dass man gerade die Styles und Javascript während der Entwicklung auch mal schnell direkt im Dateisystem anpassen kann und wenn man fertig ist, einfach die Änderungen in die Dateien in der Visual Studio Solution überträgt. Damit kann man das ständige Deployen der VS Solution umgehen und wesentlich schneller Änderungen an seinen Dateien vornehmen.

Ich hatte ja zuerst noch Bedenken, dass SharePoint (der ja die CSS Dateien parsed) Probleme mit dem Layouts-Order hat. Dies wäre fatal gewesen, da wir eigene RTE Styles in unseren CSS Dateien hinterlegt hatten, aber dies war überhaupt kein Problem. SharePoint hat die dort gelagerten CSS Dateien genauso behandelt, wie jede andere auch.

Features, die explizit die Style Library benötigen, wie z.B. Themes benutzen wir nicht, also ist auch das kein Argument dafür.

Und zu guter letzt ist der Layouts Ordner wirklich in jedem Web vorhanden und nicht nur in der Webseite auf oberster Ebene. Dies sorgt besonders bei Managed Paths dafür, dass man seine Styles wunderbar einfach einbinden kann.

Alle die oben aufgezählten Gründe, sind für mich eigentlich mehr als ausreichend, momentan auf das Ablegen von Style Dateien in der Style Library zu verzichten und stattdesssen auf den Layouts-Ordner zu setzen.

Veröffentlicht von

Morksen

Morksen

Ich bin SharePoint Systems Engineer bei der NIDAG GmbH in Mainz und in meiner Freizeit passionierter Nerd und MMO Spieler.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *