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