SharePoint 2010 RTE Styles

Sharepoint 2010 bringt ja einen durchaus brauchbaren Rich Text Editor für Page Content Bereiche und das Content Editor Webpart mit. Jetzt ist es ja aber nun üblich, dass man nicht jedes Mal sein komplettes Text-Layout mühsam im RTE einstellen möchte, sondern man möchte ja eigentlich zumindest häufig genutze Formatierungsoptionen wiederverwenden können. Microsoft hat hier mitgedacht und bringt Styles mit, die wiederverwendet werden können. Diese sind bequem im Editierungsmodus über das Ribbon erreichbar.

Sharepoint 2010 Standard Styles

Nun muss man aber zugeben, die Styles, die Microsoft dort hinterlegt hat, sind nicht unbedingt das, was man als User erwartet und vor allem entsprechen Sie erstmal keinem Corporate Design. Aber auch hier hat Microsoft mitgedacht, und so kann man eigene Styles relativ leicht hinzufügen.

Man legt sich einfach eine CSS-Datei an und fügt dort CSS-Klassen ein, deren Name mit ms-rteStyle- beginnt. Zusätzlich muss man noch das CSS-Attribut -ms-name einfügen, dass den Titel des Styles in dem Dropdown angibt.

Eine solche CSS-Klasse könnte in etwa so aussehen:

.ms-rteStyle-Notification
{
	-ms-name: "Hinweistext";
	border: 1px solid #7F0000;
	background: #FFD800;
	padding: 5px;
	color: #7F0000;
}

Wie kommt das ganze nun in meinen Sharepoint wird sich der Leser nun wahrscheinlich denken. Nun ja, man muss nun lediglich diese CSS-Datei in seinem Sharepoint einbinden. Da ich gerne vieles am Sharepoint umstyle, arbeite ich mit Visual Studio Solutions, die eigene Masterpages deployen und dort ein komplettes Branding mitbringen. Hier binden wir dann einfach die zusätzlich CSS Datei in der Masterpage ein und deployen die Solution. Natürlich gibt es auch noch andere Wege, so kann man z.B. die CSS-Datei in den Style Library Ordner hochladen, eine Kopie der v4.master anlegen, dort die CSS Datei eintragen  und in den Site Master Page Settings diese eigene Masterpage referenzieren, oder, oder, oder. Eventuell gehe ich noch mal in einem anderen Blogbeitrag auf dieses Thema ein, aber hier geht es erstmal nur um die RTE Styles.

Sharepoint interpretiert jede in der Masterpage eingebundene CSS-Datei und überführt alle Klassen, die dem oben gezeigten Schema entsprechen in das Style-Dropdown, so dass es dort einfach durch den Benutzer ausgewählt werden kann. Wichtig ist hier, dass außer dem entsprechenden Klassennamen und dem -ms-name Attribut mindestens ein weiteres CSS-Attribut angegeben wird.

Final sieht unser Beispiel dann etwa so aus

Angepasset RTE Styles im Sharepoint

Wie man sieht, sind hier schon weitere Styles eingebunden und ganz am Ende der Liste erscheint unser Beispiel-Style. An dieser Stelle muss ich aber leider darauf hinweisen, dass man diese Styles nur bedingt stapeln kann, man kann also nicht Hinweistext mit z.B. Interner Link kombinieren, solange es sich um den gleichen Bereich handelt, dem der jeweilige Style zugewiesen werden soll. Wenn man nur einem einzelnen Wort innerhalb eines Absatzes einen anderen Style geben möchte, funktioniert das schon mitunter. Ich selbst empfinde es aber von der Handhabung als etwas „frickelig“

Was für Text geht, geht natürlich auch für Bilder. Hier lautet das Präfix des CSS-Klassennamen etwas anders, die Herangehensweise ist aber identisch.

.ms-rteImage-CustomImageStyle
{
-ms-name: "Image Style";
border: 2px dotted #666;
margin: 10px;
}

Dies sieht als Ergebnis so aus:

Benutzerdefinierter RTE Style für Bilder

Im Screenshot sieht man auch sehr schön, dass dort in den Bildtools neben den Bildformatvorlagen auch noch der Button für Position ist. Auch dieser lässt sich ähnlich der oben genannten Methode überschreiben. Hier lautet das Präfix ms-rtePosition.

.ms-rtePosition-LeftTop
{
	-ms-name: "Links mit Rahmen";
	float: left;
	padding: 10px;
	border: 1px solid grey;
	margin-right: 10px;
	margin-bottom: 10px;
}

Man kann auch bestehende Style überschreiben. Die von Microsoft definierten CSS-Klassen sind:

Für Text:

.ms-rteStyle-Comment
.ms-rteStyle-Normal
.ms-rteStyle-Highlight
.ms-rteStyle-Byline
.ms-rteStyle-Tagline
.ms-rteStyle-Comment
.ms-rteStyle-References
.ms-rteStyle-Caption

Bilder:

.ms-rteImage-0
.ms-rteImage-1
.ms-rteImage-2
.ms-rteImage-3
.ms-rteImage-4

Positionen:

.ms-rtePosition-1
.ms-rtePosition-2
.ms-rtePosition-3
.ms-rtePosition-4
.ms-rtePosition-5

Durch die hier genannten Optionen, die Styles, Image Styles und Image Positions anzupassen, sind einem eigentlich keine Grenzen gesetzt. Wer gerne mit jQuery arbeitet, sich aber immer geärgert hat, dass im in RTE Textbereichen eventuell passende Selektoren fehlen, kann auch hier mit den RTE Styles arbeiten. Hier ist es zwar etwas störend, dass man immer mindestens ein zusätzliches CSS-Attribut angeben muss, aber hier kann man im Zweifel auch einfach ein beliebiges Attribut mit Default-Wert (oder sowieso schon gesetztem Wert einfügen.

Ich hoffe, dieser kleine Exkurs in die Welt der RTE Styles war halbwegs hilfreich.

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.