Remplacer les composants Web Parts dans les solutions bac à sable (sandbox)
L’une des raisons pour lesquelles de nombreux développeurs ont utilisé des solutions bac à sable basées sur du code est la volonté d’utiliser des composants Visual Web Parts. Cela offre un excellent moyen de séparer le code de la disposition et d’utiliser les ASP.NET contrôles. Vous pouvez continuer à utiliser des composants Visual Web Parts dans un add-in hébergé par un fournisseur via des composants Web Parts clients. Il s’agit d’une approche excellente qui fournit un chemin de migration direct pour de nombreuses applications.
Une autre option consiste à réécrire le partie Web Part en tant que solution côté client. Cela implique de redéfinir la solution pour utiliser JavaScript, des fragments HTML et une ou plusieurs infrastructure de prise en charge. Bien qu’il s’agit d’un travail net nouveau, il présente l’avantage de pouvoir facilement intégrer votre solution à la prochaine SharePoint Framework. Il s’agit d’un excellent choix pour les composants Web Parts d’affichage ou d’entrée de données simples, et peut être mis à l’échelle jusqu’aux applications clientes pleine page.
Notes
L’utilisation des solutions bac à sable basées sur un code est déconseillée depuis 2014 et, dans SharePoint Online, cette fonctionnalité est sur le point d’être totalement supprimée. Les solutions bac à sable basées sur un code sont également déconseillées dans SharePoint 2013 et SharePoint 2016.
Options de remplacement des composants Web Parts
| Approche | Considérations sur la conception et plus d’informations |
|---|---|
| Partie Web De client de add-in hébergée par un fournisseur |
|
| Solution côté client |
|
Suppression de code bac à sable de votre site
Lorsque vous désactivez votre solution bac à sable existante de vos sites, les ressources ou fichiers déployés à l’aide d’options déclaratives ne sont pas supprimés. Toutefois, les fonctionnalités de la solution bac à sable sont automatiquement désactivées et le récepteur d’événements est supprimé.