Archiv für den Tag: 2.9.2008

Vorweg: die aktuelle Lösung ist sicher nicht die geschickteste, da sie eine individuelle Konfiguration für jede Document Library erfordert. Aber im Rahmen des Proof-Of-Concept Ansatzes sollte das erst mal reichen. Eine erweiterte Konfiguration ist kein technisches Problem, sondern nur eine Frage des Fleisses.

Im Beispiel habe ich mir eine Document Library namens WSS Uploader Demo Library angelegt. In dieser habe ich vier neue Felder angelegt, drei davon sind Pflicht (Wahrheitswerte können nicht als Pflichteigenschaft markiert werden, sind zwar de facto immer welche, haben aber auch immer einen Vorgabewert): einen einzeiligen Text (A Text), eine Zahl (A Number), eine Auswahl (A Choice, mit den Werten Choice 1 und Choice 2) sowie den erwähnten Wahrheitswert (A Flag) – in Klammern immer die Namen der jeweiligen Felder, die gleich noch eine wichtige Rolle spielen.

Ohne weitere Konfiguration wird nun der alte Mechanismus verwendet und die ausgewählten Dateien ausgecheckt ohne weitere Eigenschaften in die Library eingespielt (man siehe die erste Zeile im folgenden Bild, die zweite wurde mit der gleich beschriebenen Konfiguration eingespielt):

Die Konfiguration für den Multi-File Upload geschieht über HTLM Fragmente, die im _app_data Unterverzeichnis der jeweiligen WSS Site abgelegt werden – etwa c:\Inetpub\wwwroot\wss\VirtualDirectories\80\_app_data für die Defaultsite auf dem Standard HTTP Port 80, _app_data exitistiert im Allgemeinen noch nicht und muss neu angelegt werden. Schon einmal wichtig am Rande: die Konfiguration wird immer beim Aufbau der Auswahlseite für Dateien ausgelesen und Änderungen erfordern keinen Neustart des Web Servers.

Für jede Document Library, die zusätzliche Eigenschaften beim Einspielen mehrerer Dateien verwendet soll, wird eine Datei der Form (für das konkrete Beispiel) MUpload_WSS Uploader Demo Library.html angelegt. Extrem wichtig sind der Anfang (MUpload_), die Dateiendung (.html) sowie die exakte Schreibweise des Namens der Library (WSS Uploader Demo Library). Für mein kleines Beispiel habe ich folgende Datei verwendet:

<table>
<tr>
<td>A Text:</td>
<td><input type="text" id="meta_A Text" value="<Please Enter>"/></td>
</tr>
<tr>
<td>A Number:</td>
<td><input type="text" id="meta_A Number" value="42" /></td>
</tr>
<tr>
<td>A Choice:</td>
<td><select id="meta_A Choice">
<option value="" selected="selected"></option>
<option value="Choice 1">Choice 1</option>
<option value="Choice 2">Choice 2</option>
</select> </td>
</tr>
<td>A Flag:</td>
<td><input type="checkbox" id="meta_A Flag" checked="checked" /></td>
</tr>
</table>

Hier sind der Kreativität des HTML Kenners keine Grenzen gesetzt. Lediglich die Datentypen der Eingabefelder (text, checkbox, select) und die Namen (id) der Eingabefelder müssen exakt eingegeben werden. Bei den Namen ist grundsätlich der Zusatz meta_ am Anfang zu ergänzen (meta_A Flag). Das war es schon!

Leider sieht man hier auch schon eines der größten Mankos, mit denen man vielleicht leben kann – schön ist es nicht: die Alternativen für mein Auswahlfeld (A Choice) werden nicht aus der WSS Konfiguration übernommen, sondern sind hier redundant eingepflegt. Sicher wäre es schöner, wenn die Eingabefelder dynamisch aus der durchaus zugänglichen Konfiguration aufgebaut würde, das ist aber mehr Aufwand, als ich für diesen Proof-Of-Concept betreiben kann und will. Der neue Seitentyp, der genau dieses HTML Fragment an die Platzhalter Position in die UPLOAD.ASPX einmischt, hat zumindest alles da, um dies theoretisch tun zu können.

Ich hoffe, diese vier Artikel reichen als Einführung.

Viel Spaß

Jochen

An dieser Stelle kommt der etwas kniffelige Teil, der mit größter Vorsicht auszuführen ist. Es ist nun eine Anpassung der Standardeinspielseite für multiple Dateien UPLOAD.ASPX notwendig – diese befindet sich im Allgemeinen im Seitenverzeichnis von WSS (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS). Ich empfehle dringend, erst einmal eine Sicherheitskopie der Datei anzulegen.

Die Änderungen umfasst drei Teile: die UPLOAD.ASPX wird an den neuen Seitentypen gebunden, es wird ein Platzhalterbereich für zusätzliche Eingaben vorbereitet und das Script zum Anstossen des Einspielvorgangs wird verändert. Bei den Veränderungen (mit NOTEPAD.EXE zum Beispiel – XML Editoren sind für HTML / ASP.NET Seiten nicht zwingend geeignet) ist zu beachten, dass nicht immer ganze Zeilen betroffen sind. Ich beschreibe im Folgende das Vorgehen basierend auf meiner lokalen Installation (WSS 3.0 mit SP1 Englisch auf Windows 2003 R2 SP2).

Gemäß den notwendigen Veränderungen finden sich im Source\Fragments Unterverzeichnis des Installationsverzeichnisses drei UPLOAD.ASPX Dateien mit den Zusätzen HEAD, FORM und SCRIPT. Diese Fragmente können zum einfachen Anpassen der UPLOAD.ASPX verwendet werden – die Zeilen mit den drei Punkten sind IMMER zu entfernen!

HEAD: Die erste Zeile der originalen UPLOAD.ASPX beginnt (!) mit einer Sequenz

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%> <%@ Page Language="C#" Inherits="Microsoft.SharePoint.ApplicationPages.UploadPage" MasterPageFile="~/_layouts/application.master" %>

Nur dieser Beginn ist durch das HEAD Fragment (ohne die letzte … Zeile) zu ersetzen.

FORM: Das FORM Fragment kann eigentlich nach Lust und Laune eingesetzt werden, wenn man sich etwas auskennt. Ich habe mich entschieden, die zusätzlichen Eingabefelder direkt unter der ‘Nicht überschreiben’ Auswahl vorzunehmen. Dazu ersetzt das FORM Fragment (ohne die beiden … Zeilen) folgenden HTML Ausschnitt:

<Template_Control>
<asp:CheckBox id="OverwriteMultiple" Checked="true" Text="<%$Resources:wss,upload_document_overwrite_version%>" runat="server" />
</Template_Control>

Hier ein Beispiel (ohne den Versuch einer Formatierung):

SCRIPT: Das alles bringt aber gar nichts, wenn nicht auch der Scriptcode beim Einspielen so verändert wird, dass er die Eingabewerte auch berücksichtigt und den neuen Einspielvorhang aktiviert. Dazu ersetzt das SCRIPT Fragment das vorhandene Script einfach vollständig (wieder ohne die beiden … Zeilen):

function _spFormOnSubmit()
{
var putoptsElement = document.getElementById("putopts");
var overwriteElement = document.getElementById("&ld;<%= OverwriteMultiple.ClientID %>");
putoptsElement.value = overwriteElement.checked ? "true" : "false";
document.getElementById("idUploadCtl").MultipleUpload();
return false;
}

Das war es erst einmal. Die Veränderungen werden nach einem Neustart des Web Servers (IISReset aufrufen) aktiv. Werden keine weiteren Schritte unternommen, sollte sich alles wie vorher verhalten. Allerdings lauern die neuen Möglichkeiten im Hintergrund gleich um die Ecke.

Soweit dazu

Jochen

Nach der Installation findet sich im Installationsverzeichnis die Assembly (DLL) JMS.SharePoint.Upload.dll, die zwei neue ASP.NET Seitentypen enthält.

Der eine Typ von Seite arbeitet völlig unsichtbar im Hintergrund und nimmt eine Anzahl von Dateien zum Einspielen in eine Document Library entgegen. Dabei wird erst einmal grundsätzlich sichergestellt, dass alle Einspielvorgänge mit einer eingescheckten Datei enden (Bug oder Feature – das lassen wir hier mal offen). Also selbst wenn nicht gesetzte Pflichteigenschaften vorhanden sind, erscheint die Datei als eingestellt in der Library. Beim Pflegen der Eigenschaften müssten die Werte dann allerdings wie gewohnt nachgepflegt werden, damit ein Speichern des Pflegeformulars möglich ist.

Anders als beim konventionellen WSS 3.0 Einspielvorgang können aber beliebig Werte zu Eigenschaften angegeben werden, die dann für alle eingespielten Dateien übernommen werden. Diese zusätzlichen Werte werden über die URL übertragen und unterliegen somit einigen Einschränkungen – bezüglich der Datentypen oder der Größe der Werte etwa: URLs können maximal 1000 Zeichen lang werden. Für den normalen Einsatz sollte dies aber kein wirkliches Problem sein. Zum Testen habe ich mit den Datentypen Text (einzeilig), ganze Zahl, Ja/Nein Wahrheitswert und 1-aus-N Auswahl gearbeitet. Es ist übrigens nicht zwingend erforderlich, dass die in der URL übertragenen Werte zu Pflichteigenschaften gehören.

Ein bißchen kritisch ist an dieser Stelle, dass die ‘nicht Überschreiben’ Einstellung des Dateiauswahlformulars nur oberflächlich ausgewertet wird. Ist das Überschreiben verboten und wird versucht, eine existierende Datei erneut einzuspielen, so wird diese ohne Warnung vom Einspielvorgang ausgenommen. Alle möglichen Einspielvorgänge werden abgeschlossen.

Der zweite Seitentyp erweitert die Standardeinspielseite UPLOAD.ASPX von WSS 3.0. Neu ist die Möglichkeit, auf der Seite Eingabefelder einzublenden, deren Werte dann mit der beschriebenen Architektur über die URL an die Einspielkomponente übetragen werden. Zur Einspielseite gibt es einen eigenen Artikel.

Die Aktivierung der neuen Seitentypen ist denkbar einfach. Erst einmal wird die erwähnte Assembly aus dem Installationsverzeichnis in alle _app_bin Unterverzeichnisse der WSS Sites kopiert, in denen eine Nutzung erwünscht ist. Ist nur eine Site installiert, so wird diese üblicherweise an den HTTP Defaultport 80 gebunden und das Verzeichnis dieser WSS Site findet sich normalerweise in c:\Inetpub\wwwroot\wss\VirtualDirectories\80 – die 80 ist der zugeordnete Port. Im Installationsverzeichnis findet sich neben der Assembly auch ein Source Unterverzeichnis mit den Quelltexten für die neuen Seitentypen. Zusätzlich sind dort im Fragments Unterverzeichnis einige Dateischnipsel angelegt, mit denen die manuelle Einrichtung vorgenommen werden kann. Die Datei MUpload.ASPX wird so wie sie ist ins Seitenverzeichnis von WSS 3.0 kopiert – üblicherweise c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.

Damit ist die erste Phase er Einrichtung abgeschlossen. An WSS selbst wurde noch nichts verändert, lediglich zusätzliche Funktionalität bereitgestellt. Diese wird aber noch nicht genutzt.

So long

Jochen