Mise à niveau des composants WebPart
Dernière modification : jeudi 1 septembre 2011
S’applique à : SharePoint Foundation 2010
Cette rubrique explique la façon la plus correcte et la plus complète de mettre à niveau les composants WebPart. Cette approche prend en compte s’il s’agit d’un composant WebPart SharePoint Foundation, hybride ou ASP.NET, si le composant WebPart est converti d’un type de composant WebPart en un autre type, le type d’action de mise à niveau et selon quels cas le code mis à niveau s’exécute ou pas. Si vous créez une nouvelle version d’un composant WebPart et devez exécuter la logique de mise à niveau sur les valeurs de propriété qui étaient stockées pour les précédentes versions du composant WebPart, Microsoft SharePoint Foundation 2010 fournit les options suivantes.
Implémentation d’AfterDeserialize
Si vos anciennes versions sont toutes des composants WebPart Microsoft SharePoint Foundation, et que votre nouvelle version est un composant WebPart SharePoint Foundation 2010 ou un composant WebPart hybride, implémentez la méthode AfterDeserialize() pour mettre à niveau le composant WebPart. Cette méthode sera toujours appelée quand l’ancienne version est désérialisée dans la nouvelle version, ce qui est le cas si le composant WebPart est une page statique (extérieure à une zone), dynamique (intérieure à une zone) ou instanciée à travers l’appel d’un modèle objet. Cependant, la méthode AfterDeserialize() ne sera appelée qu’une fois lors de la mise à niveau de l’ancienne version désérialisée vers la nouvelle version, et après que votre composant Web Part a été mis à niveau vers un composant WebPart hybride, la méthode AfterDeserialize() ne sera plus appelée. Par conséquent, si vous avez converti votre composant WebPart SharePoint Foundation en un composant WebPart hybride, puis, ensuite, ajoutez une logique de mise à niveau au composant WebPart hybride après qu’il a été déployé comme composant WebPart hybride, vous devez implémenter AfterDeserialize() pour gérer la mise à niveau d’un composant WebPart SharePoint Foundation en un composant WebPart hybride 2.0. Vous devez également implémenter les interfaces décrites ci-après pour gérer la mise à niveau d’un composant WebPart hybride 1.0 en un composant WebPart hybride 2.0. À cette fin, il est recommandé de créer une fonction de mise à niveau partagée (ici, TransformMyString) que la méthode AfterDeserialize() et vos implémentations d’interface appellent.
Si l’ancienne version du composant WebPart est un composant WebPart hybride ou un composant WebPart ASP.NET, et que la nouvelle version est un composant WebPart hybride ou un composant WebPart ASP.NET, la méthode AfterDeserialize() ne sera pas appelée et la logique de mise à niveau du composant WebPart doit être appelée depuis OnInit(), EndLoad() et Load(), en fonction de ce que la mise à niveau doit accomplir.
Pour plus d’informations sur l’utilisation de la méthode AfterDeserialize(), voir Mise à niveau d’un assembly WebPart pour les produits et technologies Microsoft SharePoint (éventuellement en anglais) et AfterDeserialize().
Détection de l’état de propriété
Imaginons que vous avez une propriété chaîne appelée SampleProperty et que le format a changé de telle sorte que votre code de mise à niveau doit transformer le contenu de SampleProperty de l’ancien format vers le nouveau format. Il est recommandé de créer une méthode TransformSampleProperty qui peut efficacement détecter si la propriété SampleProperty a déjà été transformée ou pas, et si elle ne l’a pas été, exécute la transformation. L’exemple suivant explique comment procéder :
using Asp = System.Web.UI.WebControls.WebParts
public class MyWebPart : Asp.WebPart
{
private m_dirty = false;
[Insert your standard Web Part logic here…]
private void TransformMyString()
{
if ([SampleProperty is in the old format…])
{
[Transform the SampleProperty value to the new format…]
m_dirty = true;
}
if (m_dirty && null != WebPartManager)
{
SetPersonalizationDirty();
m_dirty = false;
}
}
}
L’appel de TransformSampleProperty depuis les méthodes OnInit() et EndLoad() garantit que votre code de mise à niveau est appelé si votre composant WebPart est une page statique, dynamique ou instanciée au travers de l’appel d’un modèle objet. Il peut être nécessaire d’ajouter une propriété « mise à niveau » ou « version » à votre composant WebPart de telle sorte que TransformSampleProperty puisse définir cette propriété après la mise à niveau et que les appels suivants de TransformSampleProperty détectent efficacement si MyString a déjà été mise à niveau ou pas. Pensez à utiliser l’interface IPersonalizable pour stocker votre propriété « version », parce que cette propriété est conservée dans le magasin avec le reste des propriétés des composants WebPart. Cependant, cette propriété n’apparaît pas dans l’interface utilisateur du volet d’outils lorsque les propriétés des composants WebPart sont modifiées, ni dans le balisage du composant WebPart quand ce dernier est modifié dans Microsoft SharePoint Designer.
Dans le précédent exemple, aussitôt que le composant WebPart est désérialisé, la méthode EndLoad() est appelée, et comme il est exact que SampleProperty est à l’ancien format, le code de transformation de la valeur de SampleProperty s’exécute. Comme le composant WebPart n’a pas encore été ajouté à WebPartManager, MyWebPart.WebPartManager conserve la valeur null et SetPersonalizationDirty n’est pas appelée. Une fois que le composant WebPart a été ajouté au contrôle WebPartManager de la page, son cycle de vie devient actif et MyWebPart.OnInit est appelée. Cependant, il devient alors faux que MyString se trouve dans l’ancien format, et MyWebPart.WebPartManager devient valide. Par conséquent, SetPersonalizationDirty est appelée, ce qui déclenche un enregistrement automatique du composant WebPart mis à niveau sur la base de données de contenu, quels que soient les droits courants de l’utilisateur.
Si le composant WebPart est une page statique, il n’y a aucune prise en charge de la modification du balisage de la page après que le code de mise à niveau du composant WebPart a été exécuté, ce qui signifie que votre balisage demeure toujours dans l’état qui était le sien avant la mise à niveau, et que votre code de mise à niveau sera toujours réexécuté dans OnInit() à chaque exploration de la page. Un cas particulier est celui où le composant WebPart tente de réécrire les propriétés sur la base de données de contenu alors que la base de données est en lecture seule dans SQL Server. Cela peut se produire parce que la mise à niveau du composant WebPart est effectivement différée à la première utilisation par instance, et que la première utilisation peut se produire parce que la base de données est en lecture seule. Le composant WebPart doit être rendu, mais échouer à enregistrer la mise à jour sur la base de données.
Modification des noms de propriété
Imaginons que vous avez une propriété X sur votre ancienne version et que vous l’avez renommée en Y dans votre nouvelle version. Dans ce cas, implémentez Load() et copiez dans Y la valeur habituellement stockée dans X, puis définissez un indicateur de changement. Puis, dans la méthode OnInit(), vérifiez l’indicateur de changement et appelez SetPersonalizationDirty.L’exemple suivant explique comment procéder :
using Asp = System.Web.UI.WebControls.WebParts
public class MyWebPart : Asp.WebPart
{
private m_dirty = false;
[Standard Web Part logic here...]
void IVersioningPersonalizable.Load(IDictionary unknownProperties)
{
[Copy X into Y here…]
m_dirty = true;
}
protected override void OnInit(EventArgs e)
{
if (m_dirty && null != WebPartManager)
{
SetPersonalizationDirty();
m_dirty = false;
}
}
}
Dans l’exemple précédent, la méthode Load() est appelée si votre composant WebPart est dynamique ou instanciée au travers de l’appel d’un modèle objet, mais la méthode N’est PAS appelée si votre composant WebPart est une page statique.
L’infrastructure WebPart appelle les méthodes de l’interface IVersioningPersonalizable indépendamment des informations d’identification de l’utilisateur ; si votre code IVersioningPersonalizable marque correctement le composant WebPart comme modifié dans l’exemple précédent, cela déclenche un enregistrement automatique du composant WebPart mis à niveau sur le magasin à l’aide d’un code interne qui ne contrôle pas les informations d’identification. Par conséquent, même si un utilisateur avec des autorisations limitées (lecture, par exemple) est le premier à parcourir la page, la mise à niveau continue à se produire comme prévu.
Dans le cas d’une page statique, la méthode Load() n’est pas appelée. Cependant, vous pouvez ajouter le code dans votre appel de OnInit() pour examiner les propriétés Expando du composant WebPart (concept de contrôle ASP.Net, et non concept d’infrastructure WebPart), copier la valeur X des propriétés Expando et attribuer cette valeur à Y. En outre, dans ce cas il n’y a aucune prise en charge de la modification du balisage de la page après que le code de mise à niveau du composant WebPart s’est exécuté, ce qui signifie que votre balisage demeurera toujours dans l’état qui était le sien avant la mise à niveau et que votre code de mise à niveau de OnInit() sera toujours réexécuté à chaque exploration de la page.
Voir aussi
Concepts
Composants WebPart dans SharePoint Foundation