Mostrando entradas con la etiqueta API. Mostrar todas las entradas
Mostrando entradas con la etiqueta API. Mostrar todas las entradas

miércoles, 10 de junio de 2009

Disable SharePoint Event Firing from any source code

Sometimes we may be interested in disable events to perform some tests or processes but we're only able to execute DisableEventFiring() and EnableEventFiring() functions from a SPItemEventReceiver.

A possible solution is disable and enable event firing from any source code. To do that, you can follow the next steps:

  1. Add a new class in your namespace which inherits from SPItemEventReceiver.
  2. Create 2 functions in that new class to call EnableEventFiring() and DisableEventFiring().
Now, we can create an instance of that class in our main program class and will be able to use our functions to enable and disable events. The code should be like this:
namespace MyNamespace
{
public class MyEventFiring : SPItemEventReceiver
{
public MyEventFiring()
{
}

public void MyDisableEventFiring()
{
this.DisableEventFiring();
}

public void MyEnableEventFiring()
{
this.EnableEventFiring();
}
}

public class MyClass
{
//...
MyEventFiring mef = new MyEventFiring();
mef.MyDisableEventFiring();
item.Update(); //This Update can be executed withou event firings
mef.MyEnableEventFiring();
//...
}
}

Evitando la ejecución de eventos en SharePoint desde cualquier código

La ejecución de eventos nos puede dar problemas en determinados escenarios o para hacer pruebas concretas, por ejemplo sobre una lista determinada. Aunque existen las funciones DisableEventFiring() y EnableEventFiring(), éstas sólo se pueden invocar desde un SPItemEventReceiver, lo que hace que tengamos que ir a la lista, desactivar los eventos, realizar las pruebas y volver a asociarle los eventos, con los riesgos que ello conlleva ya que podemos dejar la lista en un estado diferente al inicial.

Una solución es hacer que se puedan desactivar y activar los eventos desde cualquier código, para ello tenemos que hacer lo siguiente:

  1. Añadir una clase en nuestro namespace que herede de SPItemEventReceiver.
  2. Crear 2 funciones, una que llame a DisableEventFiring() y otra que llame a EnableEventFiring().
Con esto ya podemos crear una instancia de esta clase en la clase principal de nuestro programa y utilizar nuestras funciones, de forma que nos quedaría algo parecido a esto:

namespace MyNamespace
{
public class MyEventFiring : SPItemEventReceiver
{
public MyEventFiring()
{
}

public void MyDisableEventFiring()
{
this.DisableEventFiring();
}

public void MyEnableEventFiring()
{
this.EnableEventFiring();
}
}

public class MyClass
{
//...
MyEventFiring mef = new MyEventFiring();
mef.MyDisableEventFiring();
item.Update(); //Este Update se podrá hacer sin que ningún evento interfiera
mef.MyEnableEventFiring();
//...
}
}

jueves, 26 de junio de 2008

Cómo adjuntar zips a SharePoint vía API y que se puedan abrir

Hace unos días comentaba los problemas de apertura y acceso al contenido de los zips adjuntados en ítems de lista de SharePoint.
Pues bien, aquí está la solución encontrada que hace que se puedan abrir correctamente y acceder a su contenido tanto con WinZip como con WinRar:
string ficheroDatos = "C:\file.zip";
FileInfo fInfo = new FileInfo(ficheroDatos);
FileStream fStream = fInfo.OpenRead();
byte[] contents = new byte[fStream.Length];
fStream.Position = 0;
fStream.Read(contents, 0, (int)fStream.Length); //leemos todo su contenido en un array de bytes content
fStream.Close();
li.Attachments.Add(ficheroDatos, contents); //en la variable li tenemos el list item al que adjuntar el zip
li.Update();

De este modo no habrá problemas al abrir los zips adjuntos a los SPListItems de SharePoint.

jueves, 19 de junio de 2008

Error abriendo zips almacenados en SharePoint

En esta ocasión quiero comentaros un problema que me he encontrado con los zips almacenados en listas y librerías de documentos de SharePoint.

Si se sube un fichero zip a través de la interfaz de adjuntar/cargar documentos de SharePoint, éstos se pueden abrir y descomprimir sin problema.
En cambio, si se hace la carga de documentos en SharePoint mediante la API o los Webservices (procedimiento normal para migraciones o cargas masivas) los ficheros quedan corrompidos y, dependiendo el programa que se use para abrirlos, obtendremos un resultado u otro:

  • WinZip no permitirá abrirlos, mostrando un error.
  • WinRar permitirá abrirlos, pero no descomprimirlos o acceder a su contenido y, si ejecutamos la verificación del fichero que ofrece WinRar, dirá que no es correcto.
Actualmente estamos estudiando este caso y os notificaremos los avances.

ACTUALIZACIÓN: Encontrada la solución al problema es cuestión, código fuente incluído.

sábado, 31 de mayo de 2008

Campos que no aparecen en custom layouts de SharePoint Designer

Estos días un compañero de Raona se encontró con un problema, estaba haciendo un custom layout con SharePoint Designer pero algunos de los campos no se dibujaban, sin seguir ninguna lógica aparente.

Después de darle un par de vueltas, nos dimos cuenta de que el problema está en los nombres que utiliza SharePoint Designer, ya que se limita a codificar el nombre del campo por completo (que debe corresponder con el InternalName del campo) pero el Internal Name tiene una longitud limitada a 32 caracteres que se puede ver desbordada por la sustitución de los espacios y caracteres extraños por la codificación del tipo _x0020_

Conclusión: con una pequeña aplicación de consola que te extraiga el InternalName del campo podrás solucionar esta situación, corrigiéndolo luego en SharePoint Designer:
SPSite site = new SPSite("http://miservidor");
SPWeb web = site.OpenWeb();
SPList list = web.Lists["nombreLista"];
SPField fld = list.Fields["campo"];
System.Console.WriteLine(InternalName: + "fld.InternalName");

domingo, 27 de abril de 2008

Ocultar campos en SharePoint 2007

Una de las cosas que se echa de menos en MOSS 2007 es la no existencia de seguridad a nivel de campo (Field) pero, al menos, existe la posibilidad de decidir si un campo se muestra o no en los formularios de las listas.

Para ello disponemos de una serie de atributos que definen si un campo debe ser visible en los formularios de New, Edit, Display y en el historial de versiones, aunque no son modificables a través de SharePoint directamente, sino que deberemos recurrir a la API.

Supongamos que queremos ocultar el campo "nombreCampo" de la lista "nombreLista" a los usuarios lectores pero que siendo posible editar su contenido, el código sería como sigue:

//Creamos el site

SPsite site = new SPSite("http://miservidor");


//Abrimos el objeto web

SPWeb web = site.OpenWeb();

//Cogemos la lista en la que queramos ocultar los campos
SPList list = web.Lists["nombreLista"];

//Cogemos el campo de la lista a ocultar
SPField field = list.Fields["nombreCampo"];

//Seteamos las propiedades del campo
field.ShowInDisplayForm = false; //El campo no se mostrará en el formulario de display de los ítems
field.ShowInEditForm = true; //El campo se mostrará en el formulario de edición de ítems
field.ShowInNewForm = true; //El campo se mostrará en el formulario de nuevos ítems
field.ShowInVersionHistory = false; //El campo no se mostrará en el historial de versiones
field.ShowInListSettings = true; //El campo se mostrará en la configuración de la lista

//Actualizamos el campo
field.Update();


Una forma sencilla de decidir en qué formularios son visibles determinados campos, eso sí, no hay que olvidar hacerlo para todas las listas en las que el campo esté presente.