Pourquoi le contrôle FileUpload est-il lié à l'élément de liste actuel dans une liste personnalisée EditForm ?

Question

J'ai écrit un formulaire d'édition personnalisé pour une liste, ce qui signifie que je perds certaines fonctionnalités prêtes à l'emploi telles que les pièces jointes, car elles faisaient partie du formulaire prêt à l'emploi.La façon dont j'ai implémenté le formulaire consiste à écrire un composant WebPart visuel personnalisé à l'aide du code ASP.NET et C#, puis pendant le déploiement, je masque le composant WebPart de modification existant dans la page EditForm.aspx, puis j'y ajoute mon composant WebPart.

La façon dont j'ai développé le formulaire repose sur une séparation appropriée des préoccupations, dans lesquelles mon formulaire ne sait vraiment rien de SharePoint et transmet simplement un objet de données à un objet gestionnaire de données qui écrit ensuite les données sur SharePoint.

Le problème vient du formulaire de pièces jointes que j'ai écrit.Ce que j'ai trouvé c'est que SPContext.Current.ListItem.Attachments contient immédiatement le fichier dans le FileUpload contrôle au retour du courrier.Je n'ai pas eu besoin d'écrire de code pour que cela se produise - il suffit de déclencher une publication pendant qu'un fichier est sélectionné dans le contrôle.

Dans la plupart des cas, je peux simplement ignorer le fait que cela se produit et que tout fonctionne correctement car je ne mets jamais à jour cette instance de l'élément de liste.Mais dans certains cas extrêmes, comme le téléchargement d'un fichier dans lequel une pièce jointe du même nom existe déjà, le formulaire explose sans même toucher à mon code.

J'ai aussi découvert qu'il y avait un AttachmentsControl dans le SPContext.Current.FormContext.FieldControlCollection et en supprimant cela dans chaque Page_Init L'événement UserControl ne résout pas du tout le problème.

La raison pour laquelle je veux que mon formulaire soit dans le contexte de l'élément de liste est que toutes les barres d'outils/ruban/menus contextuels prêts à l'emploi/etc.toujours correctement créer un lien vers le formulaire.Je pourrais rediriger du formulaire d'édition vers une page hors contexte contenant mon composant WebPart, mais cela semble hackish et inutile (sans parler d'un mauvais codage).

Quelqu'un a-t-il une idée de la raison pour laquelle ce comportement se produit et de la façon dont je peux le contourner ?Cela semble être une très mauvaise conception pour n'importe quel formulaire de liste de détourner automatiquement un contrôle pour son propre usage comme celui-ci.J'ai l'impression que SharePoint devrait avoir son propre contrôle et laisser le contrôle ASP.NET tranquille, mais cela ne semble pas être le cas.

Answer 1

sur un formulaire de liste standard Si une pièce jointe avec le même nom a été ajoutée plusieurs fois.Si l'article sera stocké, le formulaire jette une exception, que l'une des pièces jointes a été ajoutée plusieurs fois et empêche d'ajouter l'élément.

Dans votre cas, vous remplacez cette exception, ce qui provoque qu'aucune pièce jointe n'est disponible lorsque vous essayez de stocker l'élément de la liste.Pour éviter ce problème, vous devez vérifier manuellement si une pièce jointe a été ajoutée plusieurs fois sinon vous échouerez toujours.

Vous devez supprimer la partie Web de nouvelle valeur par défaut au lieu de la masquer.Ensuite, l'exception ne sera pas soulevée et vous êtes capable d'obtenir les pièces jointes.

Answer 2

Si vous attachez un gestionnaire d'événements à l'événement ItemAdding le déclenche-t-il sur les conditions d'erreur?Vous pourrez peut-être utiliser cela pour exécuter un code personnalisé pour gérer l'événement ou éventuellement supprimer le message d'erreur du système système et vous fournir votre propre plus agréable.