Dr. Jochen Manns

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