SSD: el síndrome de la Sharepoint dependencia

Sharepoint me proporciona seguridad y me hace sentir más fuerte. Las 10 cosas que más me gustan de Sharepoint.

10 puntos para entender a Project Server 2010

Microsoft Project es quizá la herramienta de gestión de proyectos más conocida y utilizada por los líderes de proyectos...

Diseño Gráfico en SharePoint

Serie de artìculos que nos ayudan a incorporar diseño gráfico en las implementaciones de SharePoint...

Revista CompartiMOSS

Artículos publicados en la revista especializada en SharePoint: CompartiMOSS.

Contacto

Enviame un correo :-)

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

viernes, 21 de septiembre de 2012

¿Cómo ordenar los combos de InfoPath 2007 con datos de listas de SharePoint?

Cuando trabajamos con formularios InfoPath 2007 en SharePoint 2007 y creamos un combo cuyo origen de datos es una lista de SharePoint nos encontramos con un problema: los datos no se pueden ordenar en forma alfabética. Este problema se da específicamente cuando el formulario se ve en formato Web.

Existe una solución relativamente sencilla a este problema que consiste en conectar el combo a una vista ordenada de la lista, en lugar de conectarlo directamente a la lista. A continuación explicaré brevemente cómo resolver el inconveniente en tres pasos:

  1. Crear una vista de la lista ordenada
  2. Reemplazar el origen de datos
  3. Publicar el formulario

 

Crear una vista de la lista ordenada

Para cada combo de nuestro formulario, creamos una nueva vista en la lista, en donde debemos cuidar sólo dos aspectos:

  • Que la vista esté ordenada
  • Que traiga todos los ítems (que no pagine)

Esto es sencillo y se hace desde el browser con las opciones estándar de SharePoint:

image

image

Una vez que hemos creado la vista, necesitamos obtener el GUID de la vista para poder usar en nuestro origen de datos dentro de InfoPath. Para ello, lo más sencillo, es aplicar un filtro a la lista, por ejemplo por el título. Veremos como cambia la URL y se agrega el parámetro VIEW en el que podremos ver el GUID de la vista, por ejemplo:

View={550179F3-6C8C-4B82-9EDA-ECC91B98BE54}

También necesitamos el dato del GUID de la lista. Lo podremos obtener fácilmente desde la configuración de la lista, también aparecerá en la URL y obtendremos algo como lo siguiente:

List=%7B0D11A089%2D561F%2D47C8%2D8EDB%2D072D646878B3%7D

que podemos convertirlo a:

List={0D11A089-561F-47C8-8EDB-072D646878B3}

Con esos datos, ya podremos crear una URL que devolverá un XML a nuestro origen de datos, ordenado:

http://surpoint/sites/sales/_vti_bin/owssvr.dll?Cmd=Display&List={0D11A089-561F-47C8-8EDB-072D646878B3}&View={550179F3-6C8C-4B82-9EDA-ECC91B98BE54}&XMLDATA=TRUE&noredirect=true

Obtendremos un XML similar a este:

image

 

Reemplazar el origen de datos

El segundo paso es más sencillo. En nuestro caso estamos editando un InfoPath creado desde un tipo de contenido. Hacemos clic en “Editar Plantilla” desde la configuración avanzada de nuestro tipo de contenido:

image

Se abrirá InfoPath y aparecerá un mensaje como el siguiente:

image

Hacemos clic en Yes y se abrirá nuestro formulario. Luego vamos a la sección de rigen de datos desde Tools / Data Connections y hacemos clic en ADD, eligiendo las opciones tal como se muestra en la siguiente imagen:

image

image

image

image

image

Luego hacemos doble clic sobre el combo que consume los datos de la lista de SharePoint. Se abrirá una pantalla llamada Drop-Down List Box Properties. En la sección Data Source, cambiamos el origen de datos que apuntaba a una lista de SharePoint. Elegimos nuestro XML ordenado.

Y luego en “Entries” elegimos el elemento que corresponda:

image

Listo, nuestro formulario se encuentra en condiciones de ser publicado.

 

Publicar el formulario

Seleccionamos la opción “Publish Form Template”:

image

Nos avisa que será grabado localmente:

image

Lo grabamos y luego seguimos el asistente de publicación tal como se ve en las siguientes imágenes:

image

image

image

En el paso final, publicamos y aparecerá una pantalla como la siguiente:

image

Luego vamos a nuestras librería (la que utiliza este formulario)y agregamos el nuevo tipo de contenido. Dentro de la sección “Cambie el orden del botón nuevo y el tipo de contenido predeterminado” podemos elegir si queremos que la versión anterior de nuestro tipo de contenido permanezca visible o no.

Y aquí termina, ya podemos utilizar nuestro nuevo formulario, pero estas vez, nuestros combos estarán ordenados.

Pueden encontrar parte de la información de este workaround en este artículo: http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx

Hasta la próxima!

viernes, 24 de febrero de 2012

Ocultar columnas en formularios de #SharePoint

No dejen de leer este post de Juan Carlos en donde encontraremos varios links para cumplir con este requerimiento con distintas opciones: PowerShell, Tipos de contenido, JavaScript, InfoPath y programáticamente.
Recomendado: http://geeks.ms/blogs/ciin/archive/2012/02/20/sharepoint-2010-ocultar-des-ocultar-campos-de-formulario-de-lista-i.aspx

viernes, 5 de agosto de 2011

Aplicaciones en SharePoint con InfoPath 2010

Estuve leyendo un artículo de David Gerhardt publicado en MSDN llamado Building SharePoint Applications with InfoPath 2010 (Part 1 of 2). A continuación dejo un breve resumen para aquellos que quieran interiorizarse en el mundo de InfoPath. Como siempre les digo, para analizar el tema en mayor profundidad, no dejen de consultar el artículo original.

Uno de los primeros temas que nos propone analizar este artículo es cómo será capturada y almacenada la información, a través del siguiente árbol de decisión:

Architecture decision tree

Para poder tomar una buena decisión, debemos analizar las características de cada herramienta. ¿En qué se destaca InfoPath?

  • No requiere un programador avanzado
  • Permite código personalizado C#
  • Preparado para navegadores
  • Cliente fuera de línea
  • Habilidades para imprimir o exportar
  • Soporta integración con flujos de trabajo

Ahora bien, si optamos por una solución InfoPath, tendremos que decidir el método de almacenamiento: librería de formularios o lista. ¿Cuáles son las diferencias?

  Formularios Listas
Estructura de datos Jerárquica Plana
Formato Archivos XML Ítems de lista
Soporte de código personalizado Si No
Soporte de cliente fuera de línea Info Path filler SharePoint Workspace
Soporte de firma digital Sí No

Un punto importante es que las listas no soportan elementos repetitivos.

Si trabajamos con el almacenamiento de tipo lista, cuando creamos un nuevo campo en InfoPath, se está creando una nueva columna en la lista. En cambio cuando trabajamos con el almacenamiento de tipo formulario, estamos creando en realidad un archivo XML, aunque disponemos de la posibilidad de mapear campos del formulario con columnas de SharePoint, lo que nos posibilita:

  • Usar filtros de vistas
  • Utilizar flujos de trabajo
  • Promover totales para los valores repetitivos

Las diferencias son, a veces, sutiles. El artículo menciona la ventaja de los formularios, si tenemos que enviar los archivos a alguien que no interactúe con el sistema. A favor del modo lista, esta la vista de edición en hoja de datos para cambios masivos, aunque esto no es estrictamente exclusivo del modo lista.

Respecto al código personalizado, debemos saber que el mismo se almacena en el archivo. Es sólo soportado por el método formulario, lo cual nos da una idea de que este método es recomendado a medida que aumenta la complejidad de la solución.

En lo que refiere al soporte fuera de línea contamos con SharePoint Workspace (ex Groove) para la modalidad lista y con InfoPath filler para la modalidad formulario.

Buenas prácticas

Lo primero que debemos saber es que la complejidad de nuestros formularios puede afectar el rendimiento de la aplicación, por ejemplo cuando agregamos formato condicional, conexiones a datos externos o código personalizado. Todo esta lógica se procesa en tiempo de ejecución lo que afecta la forma en que el formulario se muestra.

Otra buena práctica es manejar más de una vista de formulario, por ejemplo para distintos tipos de usuario, en lugar de una sola vista que contenga todas las reglas de negocio, como puede apreciarse en las siguientes imágenes:

Requestor view for a hardware request

Hardware request form approver view

Respecto a las conexiones a datos externos, es lógico que cuanto más tengamos, más se degradará el rendimiento. Una buena práctica es no cargar todas las fuentes externas en el momento en que se abre el formulario, sino esperar hasta que realmente lo necesitemos, lo cual puede depender de algún valor cargado en un campo. También tenemos la opción de convertir la información de datos externos en XML estático, lo cual sólo es factible si los datos cambian con poca frecuencia.

Existe una opción para evitar que se realicen postbacks. Si sirve para nuestro escenario, debemos considerar esta configuración. También existen consideraciones respecto al manejo de campos en cascada, que son analizadas en el segundo artículo del autor.

Otras consideraciones

Si trabajan con información de usuarios en los formularios, es importante saber que existen dos enfoques posibles: el selector de persona/grupo y el servicio de perfil de usuario.

En caso que habilitemos las opciones de flujo de trabajo tenemos saber que debemos promover los campos del formulario como columnas de lista para que estén disponibles para el flujo de trabajo. Los campos repetitivos pueden promoverse con funciones de agregación como por ejemplo: primero, último, cuenta o concatenación. No olvidar que en forma predeterminada, los campos se promueven como columnas de sólo lectura, aunque esto podemos cambiarlo.

A nivel de seguridad, tenemos tres niveles: restringido (no se puede acceder contenido externo al formulario), dominio (no se puede acceder contenido en otro máquina) y confianza completa.

Fin

Este fue un breve resumen del artículo de David Gerhardt que pueden encontrar en http://msdn.microsoft.com/en-us/library/ff961896.aspx. Espero que les haya servido para tener un primer contacto con InfoPath 2010. Hasta la próxima!

lunes, 27 de junio de 2011

Listas vs Excel vs InfoPath vs Access

¿Alguna ves tuvieron la inquietud de no saber si usar una lista. Excel, Access o InfoPath para encarar una implementación SharePoint? Es posible.

Si es así, les dejo este breve artículo proveniente de Sharepoint.Sharon, que incluye algunas reflexiones al respecto:

http://www.sharepointsharon.com/2011/06/managing-data/

Que lo disfruten, hasta la próxima!

image

Leer el artículo completo en: http://www.sharepointsharon.com/2011/06/managing-data/

martes, 4 de enero de 2011

Comparación visual de dos formularios InfoPath

Hace poco un cliente nos planteó un requerimiento en el que deseaba hacer una comparación visual de dos formularios InfoPath en una página web en Office SharePoint Server 2007. La implementación debía llevarse a cabo sin instalar código de servidor.

Para resolver el pedido, creamos una página con las siguientes características:

  1. Una lista que permite seleccionar los documentos a comparar
  2. Dos IFRAMES en donde se muestran los formularios InfoPath
  3. Un conjunto de acciones que permiten:
    • Maximizar el espacio de trabajo para la comparación visual
    • Ver los documentos don distintas opciones de zoom (100%, 75% y 50%)
    • Borrar los filtros que el usuario pudo haber aplicado en la lista de selección

El resultado es una pantalla como la siguiente:

image

Pero, ¿cómo fue la implementación? …

 

Los IFRAMES

Lo primero es crear los IFRAMES en donde se muestran los documentos INFOPATH. Eso puede hacerse con una breve instrucción en JavaScript:

function crear_iframe(id_iframe) {

  document.write("<iframe id=" + id_iframe + " name='" + id_iframe +

  " 'width=100% height='530' frameborder='0'><p>Your browser does not

  support iframes.</p></iframe>");

}

La carga de los IFRAMES

El segundo paso es la creación de los botones que permitan al usuario cargar los IFRAMES con los documentos InfoPath:

image

Estos botones contienen un hipervínculo como el siguiente que hace posible la carga de los IFRAMES:

<DIV><A HREF='' onClick='javascript:document.all.IFrameUno.src="/Evaluaciones%20de%20Desempeo/Sebastian Torres - 2009.xml?OpenIn=Browser";return false;'><IMG SRC='\_layouts\Images\icongo02rtl.gif' TITLE='Agregar a la izquierda' BORDER='0'></A></DIV>

El hipervínculo no hace más que apuntar al documento XML que se desea mostrar. Es importante la utilización del parámetro OpenIn=Browser, caso contrario intentará abrir el documento en la herramienta cliente de InfoPath.

Para crear los botones sin utilizar código en el servidor, podemos utilizar la excelente funcionalidad de HTML Calculated Column creada por Christopher en su blog Path to SharePoint, que utiliza JavaScript para convertir una columna que tiene texto HTML en HTML “real”.

Para ello necesitamos crear dos campos calculados con esta fórmula:

=CONCATENATE("<DIV><A HREF='' onClick='javascript:document.all.IFrameUno.src=";CHAR(34);"/Evaluaciones%20de%20Desempeo/";Título;"?OpenIn=Browser";CHAR(34);";return false;'><IMG SRC='\_layouts\Images\icongo02rtl.gif' TITLE='Agregar a la izquierda' BORDER='0'></A></DIV>")

La función CHAR nos permite agregar un carácter especial, en este caso las comillas dobles. La columna Título es la que contiene el nombre del archivo XML.

Una vez creada las dos columnas calculadas para cargar los IFRAMES, sólo resta agregar el código de Christopher para convertir en texto en HTML.

 

Pantalla completa y zoom

La opción de pantalla completa lo que en realidad hace es agrandar el espacio de trabajo para que el usuario puede ver con mayor amplitud los documentos. Para ello se puede utilizar jQuery para modificar los estilos y ocultar algunas zonas. jQuery nos proporciona además algunos efectos “lindos” con la función hide.

imagefunction pantalla_completa() {
  $('.ms-pagetitleareaframe').hide("slow");
  $('#MSOZoneCell_WebPartWPQ3').hide("slow");
  $('#onetIdTopNavBarContainer').hide("slow");
  $('.ms-globalbreadcrumb').hide("slow");
  $('#boton_completa').hide("slow");
  $('#boton_normal').show("slow");
}

Para la opción de zoom podemos utilizar las bondades del IFRAME, que nos permite modificar el zoom con el cual estamos visualizando la página dentro del IFRAME:

imagefunction zoom75 () {
  $('#IFrameUno').attr('style', 'zoom:75%');
  $('#IFrameDos').attr('style', 'zoom:75%');
  $('#IFrameUno').attr('height','720');
  $('#IFrameDos').attr('height','720');
}

Por último, el borrado de filtros, es un simple link a la página sin los parámetros que SharePoint agrega en el momento de aplicar un filtro:

document.write("<a href='/internal/compare.aspx'><img src='/_layouts/Images/filteroff.gif' border='0' title='Borrar filtros'></a>");

Fin

Eso es todo por hoy amigos, si bien es un caso muy particular de requerimiento, me pareció importante compartirlo. Nunca se sabe si hay alguien del otro lado del mundo tratando de hacer lo mismo.

Hasta la próxima y no duden en comentar y sugerir mejoras.

miércoles, 22 de diciembre de 2010

InfoPath en una webpart en SharePoint 2007

Les dejo estos dos enlaces que nos explican como mostrar un formulario InfoPath dentro de una webpart en SharePoint 2007.

El primero un breve artículo en español del amigo Mario Cortés Flores: http://geeks.ms/blogs/mcortes/archive/2009/03/30/infopath-mostrar-un-formulario-desde-un-webpart.aspx.

El segundo: un screencast en inglés de Andrew Woodward que aquí les dejo incrustado:

Espero que les sea útil!