Tag Archives: sharepoint

Einfluss des Browsers auf SharePoint Anwendungen

Posted on by
Reply

Jetzt lese ich doch heute einen interessanten Blog Eintrag von Sander de Koning. Er hat Messsungen gemacht, wie unterschiedlich lange die verschiedenen Browser-Versionen vom Internet Explorer für eine SharePoint-Seite haben. Interessant für mich ist diese Messung, da auch in meinem Kundenumfeld Installationen vorzufinden sind, welche mit der 6. Version des Internet Explorers existieren – und diese Kunden beklagen sich sogar über die Performance.

Nun gut, Sander hat eine SharePoint-Page zur Messung verwendet, welche eine Liste von 350 Elementen zeigt. Die Liste umfasst 7 Spalten. Das sind für SharePoint-Verhältnisse viele Daten, welche so auf einer Seite dargestellt werden. Seine Ergebnisse sahen wie folgt aus:

Browser Zeit Bemerkungen
IE6 34sec sauberes System, keine anderen Apps offen
IE7 21sec VirtualPC
IE8 im IE7 Modus 6.4sec wie IE6 System
IE8 6sec wie IE6 System
Safari 4 <4sec rendering Probleme

Ohne diese Zahlen nun zu eng auszuwerten erkennt man aber doch einen gewissen Trend: Je neuer die Version, desto schneller auch das Rendering von SharePoint-Seiten. Im vorliegenden Fall konnte die Zeit von IE6 auf einen sechstel der Zeit herunter geborchen werden, indem die neueste Version vom Internet Explorer verwendet wurde.

SharePoint Meeting-Workspace mit Javascript Fehler

Posted on by
2

Microsoft Office SharePoint Server 2007 Meeting Workspace

In SharePoint gibt es ja bekanntlich die Meeting-Workspaces, welche direkt aus Outlook heraus erstellt werden können. In diesen Workspaces können für Meetings diverse Informationen festgehalten werden, welche dann für alle Teilnehmer sichtbar und bearbeitbar sind. Wenn ein Termin als Serie definiert ist, kann auf der linken Seite zwischen den einzelnen Terminen gewechselt werden.

Sobald man nun aber ein Custom-Design verwenden will, funktioniert diese linke Spalte plötzlich nicht mehr. Die Klicks auf die Termine ergeben nur noch Javascript Fehler, welche ein Problem mit g_instanceID melden. Wenn man versucht, wieder auf das Standard-Design zu wechseln, in dem man die Masterpage default.master wieder auswählt, verbessert sich die Lage aber auch nicht mehr.

Die Ursache liegt darin, dass ein Meetingworkspace per Default eine Masterpage verwendet, welche via Browser gar nicht selektiert werden kann. Sprich: Einmal geändert, gibts kein Zurück mehr (zumindest mir nicht bekannt). Man findet die besagte Masterpage im Verzeichnis …12/TEMPLATE/GLOBAL/ mit dem Namen mwsdefault.master.

Masterpage Location auf SharePoint Server

Die Masterpage, welche verwendet werden soll (default.master, oder eine selbst Erstellte), muss nun mit Codeschnippsel aus der mwsdefault.master-Masterpage erweitert werden. Dann funktioniert der Meetingworkspace wieder in gewohnter Manier – auch im neuen Design.

In der Masterpage muss nun folgende Referenz hinzugefügt werden: <%@ Register Tagprefix="Meetings" Namespace="Microsoft.SharePoint.Meetings" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
Es gibt ja schon ein paar Register-Zeilen. Dort fügt man diese Zeile (kopiert aus der oben genannten mwsdefault.master-Datei) noch dazu. Am Einfachsten via SharePoint Designer. Das sieht dann etwa so aus (klick für grosse Version):

Register Zeile in Masterpage einfügen

Dann muss noch der Property-Bag kopiert werden. Das wäre dies hier: <Meetings:PropertyBag runat="server"/>. Dies fügt man in der Masterpage irgendwo im Body ein. Ich habs hier rein gestellt (klick für grosse Version):

Propertybag in Masterpage einfügen

Und das war es dann auch schon. Sobald die Masterpage wieder eingecheckt und veröffentlicht wurde, wird der Meetingworkspace wieder normal funktionieren und es kann zwischen den einzelnen Terminen wieder gewechselt werden.

MOSS Kalender nach Start- oder End-Datum filtern

Posted on by
1

Gestern kontaktierte mich ein Kunde, weil er es nicht schaffte, in einem SharePoint 2007 Kalender ein View einzurichten, welcher basierend auf dem Startdatum oder dem Enddatum gefiltert Einträge anzeigt. Die Site arbeitete bis vor ein paar Tagen noch mit dem SharePoint Portal Server 2003, wo er dies bisher ohne Probleme definieren konnte.

Ich habe dann das mal auf einem meiner SharePoint’s ohne Migrationshintergrund angeschaut. Völlig irritiert musste ich feststellen, dass sich so ein Filter wirklich nicht setzten lies. Damit starb meine anfängliche Vermutung, dass die SPS03-to-MOSS07 Migration das Problem war. Diverse Beiträge im Internet haben mir das nun auch bestätigt: In SharePoint 2007 Kalender kann man in einem View keinen Filter auf Start- oder/und End-Datum setzten. Eigentlich bin ich überrascht, dass ich über dieses Problem nicht schon eher angetroffen habe, ist dies ja nun wirklich nicht mein erstes SharePoint 2007 Projekt.

Variante 1: Calculated Fields

Nun gut, dem Kunde nützt kein Feedback, dass es nicht geht. Er will eine Lösung dafür – zumal es ja in der Vorgängerversion funktioniert hat. Im Internet findet man hierzu häufig die Lösung, dass man nun zwei weitere Felder hinzufügt. Beides sind calculated Fields, welche jeweils einfach die Werte der Originalfelder übernehmen (=[EndDate]). Diese berechneten Felder lassen sich dann bei der Filterdefinition verwenden.

Bei dieser Lösung berichten Andere aber davon, dass es Probleme mit der genauen Filterung von ganztägigen Ereignissen gibt. 

Variante 2: SharePoint Designer

Ich habe aber nun einen anderen Weg verfolgt: Da die gefragten Views in meinem Fall vom Setup her eher statisch sind (Filter und Feldauswahl ändern sich nicht), hab ich den View im SharePoint Designer 2007 editiert. Hier mein Vorgehen dazu:

  1. Im besagten Kalender einen neuen View erstellen (oder sich den Namen des zu bearbeitenden Views merken). 
  2. In diesem View einen Filter auf ein verfügbares Feld vom Typ DateTime setzen (z.B. “Erstellt”). 
  3. Den Vergleichsoperator und den Vergleichswert setzt man schon analog dem Endergebnis. Da ich alle Ereignisse anzeigen will, welche in der Vergangenheit liegen, lautet meine Filterdefinition “Erstellt ist kleiner als [Heute]“.
  4. Nun öffnet man den SharePoint Designer 2007, öffnet die entsprechende Site, geht zum Kalender und findet dort seinen View (ie. “Done.aspx”). Diesen öffent man nun in der Code- oder Split-Ansicht.
  5. Beim KalenderwebPart findet man nun den View-HTML-Code (all das, was mit &lt; und &gt; grosszügig vermischt ist)
  6. Jetzt sucht man am einfachsten nach “Where”. Der erste Treffer solle zu etwa diesem Abschnitt führen:
    7. &lt;Query&gt;&lt;Where&gt;&lt;Lt&gt;&lt;FieldRef Name="Created"/&gt;&lt;Value
Type="DateTime"&gt;&lt;Today/&gt;&lt;/Value&gt;&lt;/Lt&gt;&lt;/Where&gt;&lt;/Query&gt;
  7. Wenn man nun einfach den FieldRef Name auf “EndDate” (oder “EventDate”) ändert und speichert, ist es das auch schon gewesen.

WICHTIG: Wenn man diesen View nun via SharePoint wieder ansehen geht, erscheint dort etwa folgendes:

Sprich, wenn ich den View irgendwie dort nun verändere, wird die Anpassung in der Filter-Field Selektion überschrieben und das Ergebnis ist wieder filterlos.

Bewertung der Varianten

Beide Varianten haben ihre Vor- und Nachteile. Bei der ersten Variante gibt es über die Contenttypes natürlich die Möglichkeit, dass man nicht jeden Kalender nachpflegen muss, sondern die neuen Felder einmal definiert und diese dann auf alle Kalender angewendet werden. Wenn Kalendereinträge bearbeitet werden, erscheinen diese berechneten Felder auch nicht. Aber es gibt einfach 2 Felder, welche nur zu Filterzwecken existieren und sonst keine Daseins-Berechtigung haben und die Probleme mit ganztägigen Ereignissen gilt es auch zu berücksichtigen.

Die SharePoint Designer-Variante ist dazu genau das Gegenteil: Es gibt keine weiteren Felder. Es kann aber auch nicht mit Contenttypes eine Vorlage editiert werden. Diese Anpassung muss für jeden Kalender gemacht werden. Auch ist hier die Gefahr gross, dass Benutzer diese Anpassung durch ein Bearbeiten des Views überschreiben.

Schlussendlich muss jeder situativ entscheiden, welche diese (mir bis heute bekannten) Varianten sich besser eignet.