SharePoint Branding

Datasheet View überlagert Flyout-Menü

Christian Otto — Thu, 17 Nov 2011 11:41:00 GMT

Ich habe heute zu einem SharePoint-Problem recherchiert, das ich hier noch einmal kurz darstellen möchte:

Schaltet man innerhalb einer Library über die "Library Tools" von der "Standard View" auf die "Datasheet View" um, und wechselt dann wieder zurück in die normale "Browse"-Ansicht, so werden etwaige Flyout-Menüs aus der Hauptnavigation (also innerhalb von ".s4-tn") von dem Datasheet verdeckt. Das generierte Datasheet ist im DOM nicht weiteres als ein Element vom Typ "<object>", welches einige verschiede Parameter ("<param>") besitzt. Ein sehr ähnliches Szenario kennt man unter Umständen vom Einsatz von Flash, wo man als param ein "wmode" mit dem Wert "transparent" setzen muss, um ein Überlagen von Flyouts durch Flash zu umgehen.

Leider klappt das in diesem Fall nicht, und auch das Setzen von z-index-Werten bei diversen betroffenen Elementen via CSS brachte überhaupt keinen Erfolg. Ein wenig resigniert bin ich dann auch noch im Technet auf einen Thread gestoßen, der das Ganze bestätigt. Die Kernaussage dort: "The cause for that is the datasheet view overrides the onload handler. Unfortunately, there is no workaround so far and I’m sorry for the inconvenience our product brought to you." Siehe dazu http://social.technet.microsoft.com/Forums/en-us/sharepointgeneral/thread/f7cdd18b-5a61-46ad-bbae-7a6ba48240d8

Schade. Aber vielleicht immerhin auch eine Erkenntnis, dass es hierfür (zumindest ad hoc) keine Lösung gibt.

Viele Grüße,

Christian Otto
www.maximago.de

SharePoint 2010 CSS Reference Chart

Christian Otto — Thu, 20 Oct 2011 14:25:00 GMT

Jeder, der sich mit dem Thema SharePoint Branding beschäftigt, kennt wohl Heather Solomon und ihr CSS Reference Chart für SharePoint 2007.

Mittlerweile hat Heather auch für SharePoint 2010 ein entsprechendes CSS Reference Chart erstellt, und damit eine enorm hilfreiche Nachschlage-Möglichkeit geschaffen.

Das 2010er CSS Reference Chart ist zu finden unter http://sharepointexperience.com/csschart/csschart.html

Viele Grüße,

Christian Otto
www.maximago.de

Variations Label Menu erscheint nicht in custom Master Page? Ein Workaround.

Christian Otto — Fri, 01 Apr 2011 12:00:00 GMT

Wer mit Variations unter SharePoint 2010 ein mehrsprachiges System realisiert, und dabei auf eigene Master Pages baut, der kennt vielleicht das Problem:
Warum erscheint der Sprachumschalter nicht auf der Seite?

Die Lösung liegt in einer Zeile Code, die man in der Datei "VariationsLabelMenu.ascx" im Controltemplates-Verzeichnis einfügen muss:

<cms:VariationsLabelEcbMenu id ="varlabelmenu1" DataSourceID="LabelMenuDataSource" DisplayText="Links to Variations" IsCallbackMode="true" runat="server" />

Gefunden hier: http://www.khamis.net/blog/Lists/Posts/Post.aspx?ID=15

Viele Grüße,

Christian Otto
www.maximago.de

Javascript-Fehler durch Rich Text Editor und CSS im SharePoint 2010

Christian Otto — Fri, 26 Nov 2010 08:28:00 GMT

Zum Hintergrund

Bei der Bearbeitung einer Wiki-Seite ist uns während der Testphase eines Projekts ein Javascript-Fehler aufgefallen, der dafür gesorgt hat, dass sich im Ribbon die "Formatvorlagen" wie auch die "Markupformatvorlagen" nicht aufklappen ließen, diese Optionen also nicht zu nutzen waren.

Troubleshooting

Nachdem nun mit der Datei "sp.ui.rte.js" der Auslöser der Fehlermeldung feststand, ging es ans Troubleshooting. Hierzu kann man wunderbar den Skript-Debugger in den Entwicklertools (a.k.a. F12) des Internet Explorers 8 nutzen.

Dieser brachte dann vor allem als Ergebnis, dass scheinbar ein Zugriffsproblem besteht, weshalb wir für einen Moment annahmen, dass es unter Umständen an den Rechten unseres Benutzer-Accounts liegen könnte.

Als wir dann testweise dieselbe Seite einmal mit dem Firefox betrachteten, und dort das Developer-Tool "Firebug" zu Hilfe nahmen, kamen wir der Sache eindeutiger auf dem Grund.

Dort konnten wir erkennen, dass es scheinbar ein Problem mit einer von uns erstellten CSS-Datei gibt.

Die Lösung

Genau die von uns eigens für das Theming bzw. Customizing des SharePoint erstellte CSS-Datei war der Grund für den Javascript-Fehler. Naja, nicht direkt die Datei selber, sondern vielmehr die Art und Weise, wie wir die Datei in der Masterpage eingebunden haben.

Um nämlich möglichst flexibel und schnell für die Testumgebung des Kunden entwickeln zu können, haben wir die CSS-Datei auf einen unserer Server ausgelagert und in der Masterpage dann per absoluten Pfad eingebunden.

Sobald aber die "Bearbeiten"-Funktion des Ribbons genutzt wird, und die Funktionalitäten des Rich Text Editors erforderlich werden, versucht die Datei "sp.ui.rte.js" alle vorhandenen Styles aus der aktuellen Seite zu ziehen, da diese ja auch die Styles für die "Formatvorlagen" und die "Markupformatvorlagen" beinhalten (die sich in der "HTMLEditorStyles.css" im Layouts-Ordner befinden).

Was nun scheitert ist der Zugriff auf die Styles der "externen" CSS-Datei, und genau das löst den Javascript-Fehler aus.

Die Lösung lautet also: eigene CSS-Dateien für das Theming bzw. Customizing MÜSSEN auf dem System selbst liegen, idealerweise z.B. im "themeable"-Ordner, damit ein richtiger Zugriff darauf erfolgen kann.

Viele Grüße,

Christian Otto
www.maximago.de

4 Ebenen des SharePoint-Branding und das Pareto-Prinzip

Christian Otto — Thu, 25 Nov 2010 11:41:00 GMT

Ich habe bei den Jungs von SharePoint Blues einen Artikel gefunden, in dem sie die Möglichkeiten des SharePoint-Brandings auf vier unterschiedliche Ebenen aufteilen – und auch sagen, wo man aus ihrer Sicht als Designer ganz schnell abwinken sollte (Aufgrund Schwierigkeiten, Aufwand, etc.).

Das Ganze bringen sie mit dem Pareto-Prinzip in Verbindung, nach dem man 80% der Kunden bzw. Besucher bereits mit 20% seiner Arbeit überzeugen kann, man aber 80% seiner Arbeit aufbringen muss, um auch die übrigen 20% der Besucher zu überzeugen.

Ihr findet den Artikel hier: http://www.sharepointblues.com/2010/09/17/four-levels-of-branding/

Viele Grüße,

Christian Otto
www.maximago.de

Branding-Besonderheiten in SharePoint 2010

Christian Otto — Tue, 28 Sep 2010 06:54:00 GMT

Nachdem nun immer mehr unserer Kunden auf SharePoint 2010 gewechselt sind, und demzufolge entsprechende Branding-Projekte entstanden sind, möchte ich hier zum Einstieg in der SharePointCommunity einige grundlegende Erfahrungen das 2010er-Branding betreffend loswerden.

In diesem ersten Beitrag von mir sind sicher auch Details enthalten, die jetzt nicht für jeden absolutes Neuland sind, aber mir war es wichtig, mal mit einem Überblick zu starten. Los geht´s.

Schauen wir uns also die Besonderheiten und Neuerungen an, die vor allem das Entwickeln von Master Pages sowie das SharePoint-Theming generell betreffen.

Das Ribbon (oder im Deutschen "Menüband"): always on top

Das Ribbon ist eine der offensichtlichsten Neuerungen im SharePoint 2010 und wurde schon an vielen Stellen beschrieben und diskutiert. Es dockt sich im oberen Bereich des Browsers an und ist immer sichtbar, auch wenn andere Bereiche der Seite möglicherweise scrollbar sind. Dies wird dadurch gewährleistet, dass das Ribbon sich in einem eigenen Container befindet, und der Rest der Seite (durch ein clientseitiges Script, im Folgenden "ECMAScript") an die restliche, zur Verfügung stehende Browserhöhe (den Viewport) angepasst und bei Bedarf mit Scrollbalken versehen wird. Es entsteht dadurch ein "frame"-ähnliches Gefühl, das wir von vielen Webseiten noch aus den 1990er-Jahren kennen. Der obere Bereich ist fix, der untere Bereich scrollbar. Wie die Positionierung der Bereiche erreicht wird, dazu u.a. im Folgenden mehr.

Die Standard Master Page und ihr Markup im Detail

Die v4.master kommt als die neue Standard Master Page im SharePoint 2010 und bringt in ihrem Markup einige erwähnenswerte Besonderheiten mit, die hier nun kurz vorgestellt werden. Diese sind vor allem auch dann relevant, wenn man fürs Branding oder Customizing auf die v4.master zurückgreift und sie als Vorlage für eine eigene Master Page verwendet.

Schauen wir uns also den Quellcode der v4.master an bestimmten Stellen einmal genauer an.

Head

Im Head-Bereich finden wir zunächst ein Script bzw. wird innerhalb eines Scripts eine Variable mit "true" definiert, womit festgelegt wird, dass es sich tatsächlich um einen SharePoint in Version 4 (MOSS 2010) handelt:

Body

Das nächste relevante Markup steckt im body-Tag:

Das "scroll"-Attribut (nicht XHTML 1.0 Strict konform!) erzwingt im Internet Explorer ein Verbergen der Scrollleisten. Für andere Browser wird dem body-Element zusätzlich die Klasse "v4master" vergeben, mit der ebenfalls die Scrollleisten ausgeblendet werden.

Warum aber soll der body nicht scrollbar sein? Damit das Ribbon immer am oberen Browserrand "haftet", und damit seine Höhe der des Viewports, also des gesamten sichtbaren Bereichs im Browserfenster entspricht. Dies ist vor allem dann wichtig, wenn die Dialog-Fenster in Form von Popups in Erscheinung treten, da diese sich zentriert über der Seite (bzw. über dem body) positionieren.

Aus eigener Erfahrung sollte man dieses gesamte Verhalten möglichst unangetastet lassen, denn wenn man z.B. ein Scrollen der gesamten Seite erzwingen möchte (d.h. die Höhe des body ist u.U. größer als der Viewport), dann verschwinden die Dialog-Fenster möglicherweise aus dem sichtbaren Bereich!

Ribbon

Den nächsten wichtigen Bereich in der v4.master stellt das Ribbon bzw. der Ribbon-Container dar.

Das ECMAScript (s.o.), welches für die Positionierung des Ribbons verantwortlich ist, verwendet die ID "s4-ribbonrow", um den Ribbon-Container ausfindig zu machen, d.h. die ID darf nicht verändert werden.

Die Klasse "s4-pr" bringt den Container auf die volle Breite, "pr" steht dabei für "page row". Die Klasse "s4-ribbonrowhidetitle" wird verwendet, um bei der Ribbon-Positionierung festzulegen, in welchem Zustand sich das Ribbon gerade befindet. Der Wert verändert sich, sobald das ECMAScript auf der Seite initialisiert wird.

Das Ribbon-Control selbst sitzt innerhalb des Ribbon-Containers. Man sollte keine weiteren Elemente innerhalb des Containers platzieren, da dessen Höhe mittels statischer Werte gesetzt wird.

Workspace und bodyContainer

Unmittelbar auf den Ribbon-Container folgen zwei weitere essenzielle Element der Master Page: das "workspace"-Element sowie der "bodyContainer".

Das "workspace"-Element ist das Element, das scrollbar wird bzw. bleibt, auch wenn die Ribbon-Positionierung aktiv ist, stellt also quasi den "unteren Teil" der Frame-ähnlichen Ansicht dar.

Auch hier ist die ID verpflichtend und darf nicht verändert werden, da das o.g. Script das Element über seine ID anspricht. Direkt innerhalb des "workspace"-Elements sitzt der "bodyContainer", dessen ID von Bedeutung ist, da damit innerhalb des Scripts die Breite des Seiteninhalts ermittelt wird.

Beide Elemente sind also Pflicht, sonst kann das System nicht funktionieren!

Die titlerow

Weiterhin von Interesse ist die "titlerow":

Auch dieses Element muss eine spezielle ID haben, aber die Ribbon-Positionierung funktioniert auch, wenn die ID fehlt. Wenn man die ID entfernt, aber das Element belässt, so wird die Title Area nicht von der Seite entfernt, sobald man ein Ribbon-Tab öffnet, was ansonsten passiert.

Dialog-Modus/Popups

Wie schon erwähnt erscheinen die Dialog-Fenster bzw. Popups immer zentriert im Viewport des Browsers, überlagern den eigentlichen Seiteninhalt und grauen diesen im Hintergrund aus.

Bei Verwendung einer eigenen Master Page greift diese auch für die Dialog-Fenster, die innerhalb eines iFrame eine komplette HTML-Seite beinhalten, auf die das Master Page Layout angewandt wird. Dadurch kann es hier zu ungewollten Darstellungen kommen, so dass z.B. Navigations- oder Layout-Elemente in den Dialog-Fenstern erscheinen, die dort nicht gewünscht sind.

Um bestimmte Elemente auszublenden, sobald die Seite im Dialog-Modus geladen wird, wird die Klasse "s4-notdlg" eingesetzt. Diese beinhaltet ein "display: none;", und man kann diese Klasse für beliebige eigene Elemente verwenden, um diese in der Dialog-Ansicht nicht darzustellen.

ECMA-Script zur Ribbon-Positionierung

Der genaue Code, d.h. die Funktion zur Ribbon-Positionierung, findet sich in der Datei "init.debug.js" innerhalb des Layout-Ordners, dort als Funktion "FixRibbonAndWorkspaceDimensions()".

Die Logik, die die Ribbon-Positionierung verantwortet, wird auf drei Arten ausgelöst: wenn die Seite lädt, wenn das Browserfenster vergrößert oder verkleinert wird, und wenn das Ribbon vergrößert oder verkleinert wird, etwa wenn ein Tab angeklickt wird.

Folgend der Ablauf der o.g. Funktion:

Existieren die Elemente "s4-ribbonrow", "s4-workspace" und "s4-bodyContainer" (und "s4-titlerow")? Fehlt eines der drei ersten Elemente, wird die Funktion nicht ausgeführt.
Hat das "workspace"-Element zusätzlich die Klasse "s4-nosetwidth"? Wenn ja, so wird von keinem Element die Breite angepasst (hilfreich bei statischen Layouts mit festen Breiten).
Anhand von statischen Werten sowie berechneten Werten wird dann die Höhe des Ribbon-Containers ermittelt. Sofern dieser mittels "visibility: hidden" ausgeblendet ist, wird die errechnete Höhe automatisch auf 0 gesetzt.
Dann erfolgt die Berechnung des "workspace"-Containers, indem die gesamte Viewport-Höhe mit der Höhe und der Positionierung des Ribbon-Containers gegengerechnet wird. Die errechnete Höhe wird dann auf das "workspace"-Element angewandt, die Scrollleisten erscheinen dort bei Bedarf, d.h. abhängig von der Menge des dort gesetzten Contents.

Die Ribbon-Positionierung aushebeln

Möchte man die Positionierung des Ribbons umgehen bzw. so gestalten, dass das Ribbon mit dem Seiteninhalt mitscrollt, so muss man folgendermaßen vorgehen:

Die "_fV4UI"-Variable muss aus dem Head-Bereich entfernt werden.
Die ID des "workspace"-Elements muss entfernt oder verändert werden, damit das ECMAScript abbricht.
Das "scroll"-Attribut muss aus dem "body"-Element entfernt werden.
In den eigenen CSS-Dateien müssen beim "body"-Element die Werte für die Attribute "width", "height" und "overflow" an die eigenen gewünschten Werte angepasst werden.

So, dass war also mein erster (aber nicht letzter) Beitrag hier in der Community. Ich hoffe, ich habe einen guten grundlegenden Einblick in die Master Page Systematik und das Branding für SharePoint 2010 gegeben. Weitere Branding-Erfahrungen und -Tipps folgen.

Eine hilfreiche Quelle für diesen Beitrag war u.a. ein Blog-Beitrag von Jonathan Kern, zu finden unter http://blogs.msdn.com/b/sharepoint/archive/2010/04/06/customizing-ribbon-positioning-in-sharepoint-2010-master-pages.aspx

Viele Grüße,

Christian Otto
www.maximago.de