Warum wird das FileUpload-Steuerelement an das aktuelle Listenelement in einem benutzerdefinierten Listen-EditForm gebunden?

Question

Ich habe ein benutzerdefiniertes Bearbeitungsformular für eine Liste geschrieben, was bedeutet, dass ich bestimmte Standardfunktionen wie Anhänge verliere, da diese Teil des Standardformulars waren.Die Art und Weise, wie ich das Formular implementiert habe, besteht darin, ein benutzerdefiniertes visuelles Webpart mit ASP.NET- und C#-Code dahinter zu schreiben. Während der Bereitstellung verstecke ich dann das vorhandene Bearbeitungswebpart auf der Seite EditForm.aspx und füge dann mein Webpart hinzu.

Die Art und Weise, wie ich das Formular entwickelt habe, basiert auf einer ordnungsgemäßen Trennung von Belangen, bei der mein Formular wirklich nichts über SharePoint weiß und lediglich ein Datenobjekt an ein Datenmanagerobjekt übergibt, das die Daten dann in SharePoint schreibt.

Das Problem tritt bei dem von mir verfassten Anhangsformular auf.Was ich gefunden habe ist das SPContext.Current.ListItem.Attachments enthält sofort die Datei im FileUpload Kontrolle bei der Rücksendung.Dafür musste ich keinen Code schreiben – lösen Sie einfach ein Postback aus, während eine Datei im Steuerelement ausgewählt ist.

In den meisten Fällen kann ich die Tatsache, dass dies passiert, einfach ignorieren und alles funktioniert einwandfrei, da ich diese Instanz des Listenelements nie wirklich aktualisiere.Aber in manchen Grenzfällen, etwa beim Hochladen einer Datei, in der bereits ein Anhang mit demselben Namen vorhanden ist, explodiert das Formular, ohne dass mein Code überhaupt berührt wird.

Ich habe auch festgestellt, dass es eine gibt AttachmentsControl im SPContext.Current.FormContext.FieldControlCollection und dies in jedem zu entfernen Page_Init Das Ereignis des UserControl hilft dem Problem überhaupt nicht.

Der Grund, warum ich mein Formular im Kontext des Listenelements haben möchte, ist, dass alle standardmäßigen Symbolleisten, Multifunktionsleisten, Kontextmenüs usw.immer noch ordnungsgemäß auf das Formular verlinken.Ich könnte vom Bearbeitungsformular zu einer nicht kontextbezogenen Seite mit meinem Webpart weiterleiten, aber das scheint hackig und unnötig zu sein (ganz zu schweigen von der schlechten Codierung).

Hat jemand einen Einblick, warum dieses Verhalten auftritt und wie ich es umgehen kann?Es scheint ein sehr schlechtes Design für ein Listenformular zu sein, ein Steuerelement auf diese Weise automatisch für den eigenen Gebrauch zu kapern.Meiner Meinung nach sollte SharePoint über eine eigene Steuerung verfügen und die ASP.NET-Steuerung einfach in Ruhe lassen, aber das scheint nicht der Fall zu sein.

Answer 1

Auf einem Standardlistenformular, wenn ein Anhang mit demselben Namen mehrmals hinzugefügt wurde.Wenn das Element gespeichert wird, löst das Formular eine Ausnahme aus, die besagt, dass einer der Anhänge mehrmals hinzugefügt wurde, und verhindert das Hinzufügen des Elements.

In Ihrem Fall überschreiben Sie diese Ausnahme, was dazu führt, dass keine Anhänge verfügbar sind, wenn Sie versuchen, das Listenelement zu speichern.Um dieses Verhalten zu vermeiden, müssen Sie manuell prüfen, ob ein Anhang mehrmals hinzugefügt wurde, andernfalls wird es immer fehlschlagen.

Sie müssen das standardmäßige NewForm-Webpart entfernen, anstatt es auszublenden.Dann wird die Ausnahme nicht ausgelöst und Sie können die Anhänge abrufen.

Answer 2

Wenn Sie einen Event-Handler an das itemAdding-Ereignis anhängen, wird dieser bei den Fehlerbedingungen ausgelöst?Möglicherweise können Sie damit benutzerdefinierten Code ausführen, um entweder das Ereignis zu behandeln, oder möglicherweise einfach die Systemfehlermeldung unterdrücken und Ihren eigenen, schöneren Code bereitstellen.