Actualización de elementos web
Última modificación: jueves, 01 de septiembre de 2011
Hace referencia a: SharePoint Foundation 2010
En este tema se explica la forma más correcta y completa de actualizar elementos web. El enfoque toma en cuenta si el elemento web es de SharePoint Foundation, es híbrido o es de ASP.NET, si se va a convertir de un tipo de elemento web a otro, el tipo de acción de actualización que se lleva a cabo y las circunstancias en las que el código de actualización se ejecutará o no. Si va a crear una versión de un elemento web y debe ejecutar lógica de actualización en los valores de propiedad que se almacenaron para versiones anteriores del elemento web, Microsoft SharePoint Foundation 2010 proporciona las siguientes opciones.
Implementación de AfterDeserialize
Si todas las versiones anteriores son elementos web de Microsoft SharePoint Foundation y su versión nueva es un elemento web de SharePoint Foundation 2010 o un elemento web híbrido, implemente el método AfterDeserialize() para actualizar el elemento web. Se llamará a este método siempre que se deserialice la versión anterior a la nueva versión, que es true si el elemento web es estático en la página (es decir, fuera de una zona), si es dinámico (es decir, dentro de una zona) o si se ha creado una instancia de él a través de una llamada de modelo de objetos. Sin embargo, solo se realizará una llamada a AfterDeserialize() cuando se actualice desde la antigua versión deserializada a la nueva versión; después de que el elemento web se haya actualizado a un elemento web híbrido, ya no se llamará a AfterDeserialize(). Por lo tanto, si convirtió el elemento web de SharePoint Foundation en un elemento web híbrido y agrega lógica de actualización al mismo después de implementarlo como elemento web híbrido, debe implementar AfterDeserialize() para controlar la actualización de un elemento web de SharePoint Foundation a un elemento web híbrido 2.0. También debe implementar las interfaces que se describen a continuación para controlar la actualización de un elemento web híbrido 1.0 a uno 2.0. Para ello, se recomienda crear una función de actualización compartida (en este ejemplo, TransformMyString) a la cual llamen el método AfterDeserialize() y las implementaciones de interfaces.
Si la versión anterior del elemento web es un elemento web híbrido o un elemento Web de ASP.NET y la nueva versión es un elemento web híbrido o un elemento web de ASP.NET, no se llamará a AfterDeserialize() y se deberá llamar a la lógica de actualización para el elemento web desde OnInit(), EndLoad() y Load(), en función de lo que la actualización deba llevar a cabo.
Para obtener más información acerca de cómo usar el método AfterDeserialize(), vea el tema sobre la actualización de un ensamblado de elemento web de Productos y Tecnologías de Microsoft SharePoint y AfterDeserialize().
Detección de estados de propiedad
Suponga que tiene una propiedad de cadena denominada SampleProperty y que se ha cambiado el formato para que el código de actualización transforme el contenido de SampleProperty desde el formato anterior al nuevo. Se recomienda que cree un método TransformSampleProperty que pueda detectar con eficacia si ya se ha transformado SampleProperty o no y que, en caso negativo, realice la transformación. En el ejemplo siguiente se describe cómo realizar esta operación:
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;
}
}
}
Al llamar a TransformSampleProperty desde los métodos OnInit() y EndLoad(), se asegura de que se llamará al código de actualización si el elemento web es estático en la página, dinámico o si se creó una instancia del mismo a través de una llamada de modelo de objetos. Puede ser necesario agregar una propiedad "upgraded" o "version" al elemento web, para que TransformSampleProperty pueda establecer esa propiedad después de la actualización y para que las llamadas posteriores a TransformSampleProperty detecten eficazmente si ya se ha actualizado MyString. Considere el uso de la interfaz IPersonalizable para almacenar la propiedad "version", ya que esta propiedad se almacena en el almacén, junto con el resto de las propiedades del elemento web. Sin embargo, esta propiedad no aparece en la interfaz de usuario de panel de herramientas cuando se editan las propiedades del elemento web ni en el marcado del elemento web cuando se edita el elemento web en Microsoft SharePoint Designer.
En el ejemplo anterior, cuando se deserializa el elemento web, se llama a EndLoad() y, puesto que SampleProperty tiene el formato anterior, se ejecuta el código para transformar el valor de SampleProperty. Debido a que aún no se ha agregado el elemento web a WebPartManager, MyWebPart.WebPartManager sigue siendo null y no se llama a SetPersonalizationDirty. Después de agregar el elemento web a WebPartManager en la página, su ciclo de vida se convierte en actual y se llama a MyWebPart.OnInit. No obstante, MyString ya no está en el formato anterior y MyWebPart.WebPartManager se vuelve válido. Por lo tanto, se llama a SetPersonalizationDirty, que desencadena un guardado automático del elemento web actualizado nuevamente en la base de datos de contenido, independientemente de los derechos del usuario actual.
Si el elemento web es estático en la página, no hay compatibilidad para cambiar el marcado de la página después de ejecutar el código de actualización del elemento web, lo que significa que el marcado siempre permanecerá en el estado previo a la actualización y que el código de actualización siempre se volverá a ejecutar en OnInit() cada vez que se examine la página. Un caso especial se da cuando el elemento web intenta reescribir propiedades en la base de datos de contenido mientras la base de datos es de solo lectura en SQL Server. Esto puede ocurrir porque la actualización del elemento web está diferida de manera eficaz para que la use primero la instancia y es posible que el primer uso se produzca mientras la base de datos es de solo lectura. El elemento web se representará, pero no podrá guardar la actualización en la base de datos.
Cambio de nombre de propiedad
Supongamos que tiene una propiedad X en la versión anterior y le ha cambiado el nombre a Y en la nueva versión. En este caso, implemente Load(), copie en Y el valor que estaba almacenado en X y establezca un marcador de modificado. A continuación, en el método OnInit(), compruebe que existe el marcador de modificado y llame a SetPersonalizationDirty. En el ejemplo siguiente se describe cómo realizar esta operación:
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;
}
}
}
En el ejemplo anterior, se llama a Load() si el elemento es dinámico o si se creó una instancia del mismo a través de una llamada de modelo de objetos, pero NO se llama a este método si el elemento web es estático en la página.
El marco del elemento web llama a los métodos de interfaz IVersioningPersonalizable, independientemente de las credenciales del usuario y, si el código de IVersioningPersonalizable marca correctamente el elemento web como modificado en el ejemplo anterior, se desencadena un guardado automático del elemento web actualizado nuevamente en el almacén mediante código interno que no comprueba credenciales. Por lo tanto, incluso si un usuario con permisos limitados (por ejemplo, el lector) es el primero que explora la página, la actualización aún se produce como estaba previsto.
En el caso de página estática, no se llama a Load(). Sin embargo, puede agregar código en la llamada a OnInit() para examinar las propiedades expando del elemento web (un concepto de control de ASP.NET, no un concepto de marco de elemento web), copie el valor de X de las propiedades expando y asigne este valor a Y. Además, en este caso no hay compatibilidad para cambiar el marcado de la página después de ejecutar el código de actualización del elemento web, lo que significa que el marcado siempre permanecerá en el estado previo a la actualización y el código de actualización de OnInit() siempre se volverá a ejecutar cada vez que se examine la página.
Vea también
Conceptos
Elementos web en SharePoint Foundation