Los manejadores de eventos constituyen una de las funcionalidades más sencillas de utilizar a la hora de extender nuestras aplicaciones de SharePoint a través del desarrollo. Básicamente permiten agregar comportamiento a nuestra aplicación e implementar reglas de negocio.
Este post pretender describir todos los aspectos de esta técnica, desde la parte conceptual hasta la parte de código con algunos ejemplos en Visual Studio. Está basado en el webcast que dicté el 16/12/2009. Como siempre, espero que les sea útil.

WebCast

Si desean ver el webcast, pueden hacerlo desde:

Si desean ver la presentación que utilicé en el webcast pueden verla aquí:

Introducción

Los manejadores de eventos permiten extender a través de desarrollo una aplicación SharePoint. Agregan comportamiento a listas e ítems entre otros. Un manejador de evento se ejecuta automáticamente como respuesta a un evento como agregar una columna en una lista o modificar un ítem en una lista. Pueden servir para:

  • Validaciones de datos
  • Control de integridad referencial
  • Control de unicidad
  • Ejecución de procesos de negocio
  • Lo que no puede resolver un campo calculado
  • Protección de la parametrización
  • Cambios en la seguridad
  • Controles de seguridad funcional

Si conocen triggers de base de datos, verán que tienen un cierto parecido. Si bien son más potentes, podríamos decir que todo lo que se hace con un trigger, puede hacerse con un evento en SharePoint. Esto puede darles una idea del potencial de esta técnica.

¿Qué eventos maneja SharePoint?

El siguiente gráfico resume los eventos soportados por SP. Pueden observar que existen eventos a nivel de ítems de lista (los que se parecen a los triggers), pero también eventos a nivel de lista, sitio, colección de sitio o característica:
image

Imaginen lo que se puede hacer…

A continuación les daré algunas ideas de lo que se puede hacer con eventos. Son sólo ideas. Es mucho más lo que se puede hacer, pero les servirá de inspiración. Lo importante es que realmente resuelven temas que no existen en SP “out of the box”, en forma bastante sencilla:
image

Tipos de eventos ¿antes o después? ¿sincrónicos o a-sincrónicos?

Es importante aclarar que existen dos tipos de eventos, los que se ejecutan antes de que se efectúe el “commit” de la transacción en la base de datos de contenido y los que se disparan luego de que se ejecute el “commit”. Los primeros son sincrónicos, los segundos a-sincrónicos (en SP 2007, en 2010 es configurable).
image
El siguiente es el mapa completo de todos los eventos que SP 2007 maneja, incluye sus variantes sincrónicas y a-sincrónicas:
image

Evento o Flujo de Trabajo

Por sugerencia de Angel Acha Lizama luego del webcast, me pareció importante incluir una breve comparación entre Eventos y Flujos de trabajo porque son técnicas que tienen algún punto en común y el lector podría encontrar difícil la decisión de cuál usar en cada caso.
En líneas generales tengan en cuenta que un flujo de trabajo suele tener interacción con los usuarios a través de pantallas, puede perdurar en el tiempo (días, semanas, meses, etc.) y requiere persistir la información.
Un evento responde a una transacción y se ejecuta en el momento, no tiene pantallas asociadas, su duración es breve y no debe ser retomado luego de un tiempo, como sucede con un flujo de trabajo.
Les dejo este enlace que me pasó Angel, si quieren ampliar el tema: http://msdn.microsoft.com/en-us/library/ee413841.aspx

Pasos para crear un evento

La siguiente lámina muestras los pasos que se deben seguir para crear un evento. No estamos usando ninguna herramienta, ni extensión para SharePoint que nos facilite la creación, con el fin de explicar los conceptos básicos.
image

Paso 1: crear el proyecto

Si necesitan ayuda con este paso, les dejo este enlace que lo explica en forma detallada: http://sharepoint-puntodeencuentro.blogspot.com/2008/09/registrar-un-evento-mediante-una.html

Paso 2: definición de una clase

Ejemplo muy sencillo de definición de clase, cuyo objetivo es impedir que un administrador agregue columnas en una lista:
image

Paso 3: binding

Existen dos formas de vincular la definición de una clase de un evento a una entidad (lista, característica, etc): 1) a través de XML dentro de una característica y 2) programáticamente. Estas dos formas apuntan a objetivos distintos. A continuación veremos dos ejemplos:

Binding XML
image


Observaciones

  • Sólo pueden registrarse en características cuyo ámbito sea «site».
  • Sólo se puede registrar el evento para un «tipo de lista», no para una lista en particular.
  • También se puede registrar eventos para tipos de contenidos o features.
  • «SequenceNumber» indica el órden cuándo tengo más de un evento.
Binding en forma programática

A diferencia de la opción vía XML, nos permite vincular un evento a una lista específica, en lugar de a un tipo de lista. Ejemplo:

image

Demostraciones

A continuación dejamos el código fuente de las demostraciones que presentamos en el webcast. Tengan en cuenta que se trata de un prototipo, no una aplicación final, por lo cual nos hemos tomados algunas licencias para escribir código y notarán algunas desprolijidades.

Demo 1: completando una columna en un evento de ítem

Este ejemplo muestra como completar un campo dentro de un evento. En el código pueden ver dos ejemplo, un caso común para el campo “Proyecto” y otro para un campo de tipo URL, el campo “Actividad”.

image 

Demo 2: validando integridad en un evento de ítem

El siguiente ejemplo muestra cómo validar “unicidad” de una columna y cancelar la operación, emitiendo un mensaje al usuario, en caso que no se cumpla esta restricción.

imageimage 

image 

Demo 3: ejecutando un proceso de negocio en un evento de ítem

Este ejemplo muestra cómo a partir de la creación de un ítem, se dispara la creación de ítems en otra lista. Muestra cómo se leen los datos de la lista origen, cómo se recorren esos datos y como se crean los ítems en la lista destino.

imageimage image

Demo 4: ejecutando un evento al instalar una característica

Este último ejemplo nos muestra un ejemplo de evento para una característica. El objetivo es hacer cambios de estilos en SharePoint. Para una explicación más amplia pueden consultar este enlace: http://surpoint.blogspot.com/2009/07/cambios-de-estilos-en-sharepoint.html.

image

Paso 4: instalar

No voy a bajar a detalle con este paso, pero quería dejarles el contenido del .”bat” en dónde se muestra la instalación de la dll en la GAC, el copiado de los archivos XML y la instalación de la característica en SharePoint:

image

SharePoint 2010

El siguiente gráfico resume las novedades en SharePoint 2010 respecto a eventos. Lo más importante es saber que hay algunos eventos nuevos, pero fundamentalmente que los eventos “before” pueden ser sincrónicos o a-sincrónicos. Al final de este artículo les dejo un enlace por si necesitan ampliar este tema.

image

Un tema relacionado que no debemos dejar pasar es que SP 2010 agrega el concepto de validación de campos “Out of the box”. Esto es mucho más sencillo de usar que programar un evento para validar de datos. La validación se arma con fórmulas similares a la de los campos calculados y es posible especificar el mensaje de error para el usuario. Estas validaciones se pueden crear a nivel de columnas de sitio, o columnas dentro de una lista.

image

Fin

Aquí termino. Espero que les haya sido útil y lo hayan disfrutado. Hasta la próxima!

Bibliografía y enlaces interesantes

image Libros

  • Inside Microsoft Windows SharePoint Services 3.0 (Chapter 6)
  • By Ted Pattisonand & Daniel Larson (Microsoft Press)

Artículos

por Juan Pablo Pussacq Laborde , el 17.12.09 0 comentarios

Click on pen to Use a Highlighter on this page
Tagged with:
 

Background:
There is no parent-child relationship support in MOSS 2007 lists by default. But as a developer, we all know it is the most common functionality while storing and displaying the data. Following is the technique that I discovered somewhere on the internet to display the data using DataView Control in SharePoint Designer(while developing reports for my last project), but unfortunatily I lost the original source and thought to reproduce it in my blog with some enhancements.

Implementation:
Following are the steps to perform Inner Join on two lists using DataView Control in SharePoint Designer:

1. We need following two lists(with data in them):

  • Department (ID, Title)
  • Student (ID,Department_x0020_ID, Title)

    2. Open SharePoint Designer and create a new ASPX page.

    3. Create a linked datasource by following steps:

    1. Select Create a new Linked Source… from Data Source Library tab.
    2. In Data Source Properties dialog, select Configure Linked Source… button.
    3. From Link Data Sources Wizard, select Students and Department Lists and hit Next.
    4. Choose Join the contents… option and select Finish.
    5. Then select OK to get the New Data Source.
    6. Expand the New Data Source and select Show Data option.
    7. Under Data Source Details tab, you should see both lists (Department and student).

    4. Insert a Data View control into the ASPX page.
    5. Under Data Source Details tab, expand the Students list and drag and drop the Title column to Data View control and it will display all the students.
    6. Now place your cursur in Title column and select Table -> Insert -> Column to Right. In this column we will display Department.Title.
    7. Place your cursor on the first row of new column, select Title Column from Department list and select the Insert selected field as… button and choose Joined Subview opion.
    8. In Join Subview dialog, select Department_x0020_ID = ID and hit OK. (Pic 12)
    9. Thats it :o ).
    10. Play with the HTML to make it look like a report.

  •  

    http://mysplist.blogspot.com/2009/12/inner-join-two-lists-using-sharepoint.html

    Click on pen to Use a Highlighter on this page
    Tagged with:
     

    Un Workflow (Flujo de Trabajo) tiene por objetivo ser un modelo de un proceso de negocio (o producción) e implica un conjunto de actividades (tareas) que se aplican y operan en forma progresiva. El Workflow describe el orden de ejecución y las relaciones de dependencia entre las distintas activdades para que estas trabajen progresivamente a través de un modelo desde un inicio a un fin. Estas son actividades realizadas por las personas en forma manual y/o con el apoyo de funciones del sistema. 

     El Motor de Workflow en “Tiempo de Ejecución” (Runtime)

    Cada instancia de un workflow en ejecución es creada y mantenida en tiempo de ejecución por un motor que actúa en el domino de proceso de una aplicación determinada (in-process runtime engine) y que la da albergue. Pueden existir varios procesos en ejecución dentro del dominio de proceso de una aplicación, cada instancia del motor en ejecución puede soportar multiples instancias de workflow que se ejecutarán de modo concurrente y podrán orquestar un conjunto de tareas o actividades.

    Cuando un módulo de workflow se compila, este puede ser ejecutado “dentro” de cualquier proceso Windows, incluyendo una aplicación de consola, aplicaciones basadas en formularios, Servicios Windows, Sitios Web de ASP.NET, y Servicios Web, entre otros, como por ejemplo, los workflows que podemos ejecutar dentro de los procesos de SharePoint (independientemente de su versión). A este proceso lo llamamos “hosted” (alojados) en proceso, la idea es que el flujo de trabajo pueda comunicarse facilmente con la aplicación que le da alojamiento.

    Asi por ejemplo, un workflow asociado a una biblioteca de documentos de SharePoint puede comunicarse a través de eventos con la instancia de la biblioteca de SharePoint que le da alojamiento (con la que se vincula). Si el vinculo se pierde estas piezas de software ya no podrían comunicarse entre sí.

    Estudiando la ilustración siguiente podemos comprender esquemáticamente como se realiza este proceso de alojamiento (hosting), cual es el orden en que se comunican y se determinan entre si las distintas piezas de software que los desarrolladores construimos. 

    Aa349006.44c79d1d-178b-4487-87ed-3e33015a3842(en-us,VS.90).gifEn particular, respecto de SharePoint, podemos construir estas piezas de software básicamente con 3 herramientas.

    1.- SharePoint Designer (una herramienta poderosa y muchas veces insustituible, seguramente con la versión 2010 lo seguirá siendo, es recomendable aprender a usarla, para un desarrollador que espera avanzar en profundidad y amplitud el peor error que puede cometer es despreciar su utilidad.)

    2.- Visual Studio (2005, 2008 y ahora 2010, siempre mejorando e imprescindible a la hora de tener que satisfacer requerimientos sofisticados por parte de nuestros queridos clientes. Un programador no puede olvidar jamás esa máxima de la economía que dice: el cliente siempre tiene la razón. Y todo es posible, solo son horas sillas, algunos dolores de cabeza, pero siempre mas tiempo y costos más elevados..je..je.. cada quien paga su propio costo…je..je.je.., nosotros dispuestos a la esclavitud de la silla, y nuestros clientes a decidir entre tiempo y costos, ROI y TCO… en fin Anton Pirulero… cada cual atiende su juego.. es la moraleja.)

    3.- Herramientas de Terceros. De estas hay varias en el mercado, distintas en funcionalidades y costos, la herramienta de mejor relación costo-funcionalidades es sin duda Kaldeera.

    Un par de links al respecto.

    Kaldeera Diseñador de Workflows.

    Y el sitio de Tito… Aquí.

    Para Workflow en el MSDN pulse acá.

    Esperando que les sea útil, y por supuesto esperando quejas, contribuciones, insultos, etc…je..je..

    Un abrazo

    Rolando

    Click on pen to Use a Highlighter on this page

    He aquí un muy buen artículo:

    http://rdiazconcha.com/?s=sharepoint+lists&x=24&y=21

    Tal vez esta pregunta todos nos la hemos hecho siquiera alguna vez. Con tantas tecnologías disponibles, tantos acrónimos y tantas opciones técnicas y de aprendizaje que tenemos hoy en día parece ser que la respuesta a esta pregunta ya no es tan sencilla como parece.

    Tal vez muchos responderán en este momento: “Estudiando” o “Asistiendo a un curso”, pero: es eso suficiente?

    He aquí la lista de cosas que -en lo personal- trato de hacer para poder ser un mejor desarrollador. La idea es que esta lista se enriquezca con la participación suya y de sus ideas.

    * Reconocer que no sabes nada
    o Por qué? Este sencillamente, es el punto principal y más crítico ya que lo primordial -como en cualquier otro proceso de aprendizaje- es reconocer y aceptar nuestra ignorancia frente a tantos y tan grandes temas y tecnologías. Quitarnos el egocentrismo nos permite abrir nuestra mente a otros conocimientos y a otras inquietudes. Finalmente, todos aprendemos de todos algo nuevo todos los días. Recordemos que la monotonía es la base de la mediocridad.
    * Escuchar podcasts
    o Por qué? Puedes reproducir el podcast una y otra vez, en tu iPod/Zen/Zune, en tu auto, en la oficina, gimnasio, antes de dormir, etc., es decir: puedes estar en contacto con el tema en cuestión en cualquier momento y combinarlo con alguna otra actividad (ojo al conducir por favor, ya que no es buen pretexto “choqué porque estaba escuchando cómo se crea un workflow en WF oficial….”)
    o Pero cuáles? Bien, si entiendes el idioma anglosajón te recomiendo dos magníficos podcasts: Hanselminutes de Scott Hanselman y ArCast de Ron Jacobs. Estos podcasts tratan diversos temas y lo mejor es que siempre están a la vanguardia, además de que son bastante amenos. Si definitivamente estás buscando algo en nuestro vasto idioma te recomiendo el Podcast que mi buen amigo Luis Du Solier prepara frecuentemente con su característica pasión por la tecnología (SharePoint principalmente).
    * Ver WebCasts
    o Por qué? Me gustan los WebCasts porque demuestran y explican con recursos visuales un tema, mientras que los Podcasts se limitan a audio.
    o Pero cuáles? Te recomiendo: http://www.microsoft.com/events/default.mspx para recursos en inglés y http://www.microsoft.com/spanish/msdn/latam/mediacenter/webcast/default.aspx para recursos en español.
    * Ver ScreenCasts
    o Por qué? Los ScreenCasts son pequeños fragmentos de video en donde se demuestra un tema muy específico de la tecnología. Son excelentes fuentes de conocimiento ya que nos llevan de la mano para efectuar la o las tareas que necesitamos realizar para alcanzar el objetivo deseado.
    o Pero cuáles? Claro está que depende de la tecnología. Qué tal los ScreenCasts de ASP.NET, AJAX, Silverlight y Workflow Foundation para empezar?
    * Participar en Foros
    o Por qué? Los foros son un recurso básico cuando tenemos duda acerca de una duda muy específica acerca de la tecnología. “Foro” en el contexto que estoy explicando se refiere tanto a los foros en páginas web, como los Grupos de Noticias o Newsgroups. Además tenemos la oportunidad de participar también en responder preguntas de otras personas en el mundo que tengan un problema y que tal vez tú sabes cómo arreglarlo.
    o Pero cuáles? Cada tecnología tiene su foro. Yo en lo particular visito frecuentemente los foros de Workflow Foundation y de Silverlight.
    * Participar en Comunidades
    o Por qué? Qué mejor que aprender de otros en persona, de frente, en vivo y a todo color acerca de un tema. Para esto precisamente sirven las Comunidades .NET, para programar y organizar reuniones entre personas geográficamente cercanas y platicar de un tópico en específico.
    o Pero cuáles? Siempre hay una Comunidad cerca de ti, visita MSN Groups para más información.
    * Leer libros
    o Por qué? La respuesta es más que obvia. Los libros son la fuente de conocimiento de cualquier tipo (tantos siglos de historia de la imprenta no pueden estar equivocados). Pero cuáles? A mí en lo personal me gustan mucho los libros Programmer-To-Programmer de la editorial Wrox (sí, esos libros de color rojo que tal vez has visto alguna vez). Otra serie de libros que a mi parecer es excelente es Microsoft .NET Development Series ya que las obras están escritas por verdaderos expertos en el tema.
    * Leer blogs
    o Por qué? Un Web Log o simplemente Blog es la bitácora personal de ideas, pensamientos o artículos técnicos de su autor. Un ejemplo muy sencillo es este blog, en donde yo su autor estoy escribiendo y agrupando las diferentes maneras o estrategias que podemos seguir para ser mejores desarrolladores. Es el alfa y el omega relacionado con este tema? Obviamente no lo es ni siquiera pretender serlo. Es simplemente sintetizar lo que yo hago con respecto a este tema en específico y darlo a conocer al público para esperar retroalimentación al respecto.
    o Pero cuáles? Podría poner aquí toda la lista de mis feeds pero me voy a limitar a poner los que leo diariamente:
    + ScottGu
    + Soma
    + Silverlight
    + Eric Sink
    + Joel on Software
    + Misael Monterroca
    + Miguel Morán
    + Jaime Sánchez
    + SharePoint en Español
    + LuisDans
    + Erika Ehrli
    + Channel9
    * Aprender a usar otras tecnologías
    o Por qué? Si bien somos geeks y nos apasionan las tecnologías y plataforma de desarrollo Microsoft, estaríamos ciegos o locos si no reconocieramos que hay otras excelentes tecnologías y que no todos en este mundo utilizan las mismas herramientas que nosotros. Por otro lado no es necesario que sean tecnologías no-Microsoft. Por ejemplo IronRuby es una tecnología que no conozco pero se me hace lo suficientemente poderosa e interesante como para ponerme a investigar acerca de ella.
    o Pero cuáles? Hay muchísima tela de dónde cortar. Por mi parte estoy usando, investigando y aprendiendo a usar ActiveRecord. Otras tecnologías que están en mi lista de “Para Próximo Estudio” son IronRuby, IronPython, F#, Microsoft Sync Framework y ASP.NET MVC Framework.
    * No procrastinar
    o Por qué? Hasta el momento hemos mencionado una lista de recursos que podemos usar como apoyo para estudiarlas y ser mejores desarrolladores. Pero falta la técnica y estrategia, y estas no son nada menos ni nada más que la Disciplina. Requerimos sin duda una fuerte disciplina para ser mejores desarrolladores y dejar a un lado los quitatiempos. YouTube, FaceBook, MSN Messenger son solo algunos de los que se me vienen a la mente y los cuales son una tremenda pérdida de tiempo. No excusas por favor, pues recordemos cómo trabajabamos hace 10 años. Midamos nuestro grado de procrastinación: Si crees que esta medida es muy drástica, que no puedes dejar de visitar los sitios anteriores o de usar tu mensajero favorito entonces tienes un serio problema de procrastinación. Si al contrario estás dispuesto a dejar de perder el tiempo y ponerte a estudiar te felicito, tu procrastinación aun es curable.
    * Relacionarte con personas apasionadas por el desarrollo de software
    o Finalmente, es muy importante encontrar personas que tengan las mismas inquietudes por aprender, conocer más y superarse (ver primer punto). Una vez que las encuentres será muy útil que platiques y te apoyes con ellas para tu proceso de mejora personal . El proceso será menos tedioso y más divertido.

    Aunque este artículo en realidad no tiene el objetivo de ser un meme me gustaría que para este tema participaran en especial las siguientes personas:

    * Misa
    * Mike
    * LuisDans
    * Nazul
    * Jaime
    * Pedro Pablo
    * Luis
    * Abraham
    * Juan Pablo

    Claro está que quien sea está invitado(a) a participar en este orden de ideas.

    Sal2

    Click on pen to Use a Highlighter on this page
    Tagged with:
     

    Una tarea muy habitual al trabajar con MOSS y WSS3, es trabajar con Páginas Web. Podemos pensar en un principio, que en MOSS y WSS3 sólo existen Páginas Básicas (Basic Pages) y Páginas de Web Parts (Web Part Pages). Sin embargo, esto es sólo parte de la historia, que se empieza a complicar con las Páginas Maestras (Master Pages), Hojas de Estilo CSS, y sobre todo al activar la característica Office SharePoint Server Publishing, introduciendo las Páginas de Publicación (Publishing Pages), las Páginas Plantilla (Layout Pages), los Controles de Campo (Field Controls), etc.

    Conocer el funcionamiento de las páginas Web de MOSS/WSS3, es un aspecto básico para el mantenimiento de cualquier instalación de MOSS 2007, más aún, para el desarrollo y personalización de este tipo de entornos.

    Este artículo sirve como introducción a la páginas Web, tal y como se entienden desde el punto de vista de MOSS y WSS3. Para ello, vamos a introducir varios términos utilizados en MOSS y WSS3, a través de los cuales vamos a ser capaz de diferencia los tipos de páginas Web existentes en SharePoint.

    Páginas Básicas (Basic Pages) y Páginas de Web Parts (Web Part Pages)

    Los principales tipos de páginas en MOSS y WSS3 son las Páginas Básicas y Páginas de Web Parts (Web Part Pages). En ambos casos, se trata de Páginas de Contenido (como veremos más adelante), diferenciándose justo es eso, en el contenido que pueden tener.

    • Una Página Básica (Basic Page) permite almacenar contenido HTML, es decir, texto, imágenes, etc.
    • Una Página de Web Parts (Web Part Pages) permite definir una serie de zonas especiales, denominadas zonas de Web Part (Web Part Zones), que deseamos utilizar en la página y sobre las que podremos ubicar contenidos a través de Web Parts. Una vez creada una nueva página de Web Parts, es posible editarla, añadiéndola las Web Parts que consideremos oportunas a las zonas de Web Parta que contenga la página. Por ello, este tipo de páginas es más rica que las Páginas Básicas (Basic Pages), ya que utilizando Web Parts podríamos almacenar contenido HTML (texto, imágenes, etc.), pero además, podríamos utilizar Web Parts para acceder otras aplicaciones externas o realizar tareas más complejas. Por verlo de forma gráfica, la página principal de un Sitio de MOSS, suele ser una página de Web Parts.

    Una Web Part es la pieza básica de construcción de una Página Web de Web Parts (Web Part Pages). Así, existen múltiples Web Parts disponibles de serie con el producto que podremos utilizar sin coste añadido, y además, es posible crear nuevas Web Parts personalizadas utilizando Visual Studio (o bien, adquirirlas en el mercado, o como parte de un producto comprado, como pueda ser Business Objects, Exchange Server, etc.). Un importante detalle, es que en función de las características que tengamos activadas, podremos utilizar unas Web Parts u otras, es decir, determinadas Web Parts no estarás disponibles para su utilización hasta que activemos la característica correspondiente.

    Podemos crear una nueva página (sea una Página Básica o una Página de Web Parts), de la misma forma que creamos otros contenidos en MOSS. Por ejemplo, podemos hacer click en la parte superior del menú de inicio rápido (es decir, el menú de la izquierda) sobre la opción View All Site Content, y seguidamente hacer click en la opción Create. Con esto, llegaremos a la página de creación de contenidos, dónde tendremos las opciones Basic Page y Web Part Page en la sección Web Pages. El principal dato necesario para crear estas páginas, es la Librería de Documentos que queremos utilizar para almacenarlas, pues estas se almacenan de la misma forma que cualquier otro documento.

    Página Maestra (Master Page)

    Una Pagina Maestra (Master Page) es una página Web especial, en la que es posible incluir diferentes configuraciones (CSS, Navegación, Ayuda, Búsqueda, etc.) y código, con el objetivo de que pueda ser heredado a través de otras páginas Web, denominadas Páginas de Contenido. Su objetivo es muy simple: permitir reutilizar el código y homogeneizar el diseño de todas las Páginas de Contenido que implementan la misma Página Maestra. Se trata de una tecnología propia de ASP.Net, y claro, MOSS y WSS3 no deja de ser una aplicación ASP.Net.

    Habitualmente, un Sitio Web de MOSS/WSS3 utiliza una única Página Maestra (Master Page), aunque es posible utilizar múltiples Páginas Maestras en un único Sitio Web. Si deseamos ver las Páginas Maestras (Master Pages) disponibles en una Colección de Sitios, así como agregar nuevas Páginas Maestras, etc., deberemos acceder a la opción Master Pages de la sección Galleries, en la configuración del Sitio Principal (Site Settings) de la Colección de Sitios (NOTA: si activamos la característica de Sitio Office SharePoint Server Publishing, utilizaremos la opción Master Pages and Page Layout de la sección Galleries).

    En MOSS es posible diferenciar entre dos tipos de Páginas Maestras (Master Pages), en particular, al activar la característica Office SharePoint Server Publishing Infraestructure a nivel de Collección de Sitios (Site Collection Features): Site Master Pages y System Master Pages.

    Así, al activar la característica Office SharePoint Server Publishing Infraestructure a nivel de Collección de Sitios (Site Collection Features), se incluirá una nueva opción en el menú de configuración (Site Settings) del Sitio Principal y SubStios de la Colección de Sitios afectada. Se trata de la opción Master Page de la sección Look and Feel, como se puede mostrar en la siguiente pantalla capturada (no confundir con la opción Master Pages de la sección Galleries):

    A continuación se muestra una pantalla capturada de lo que se ve al hacer click sobre la opción Master Page de la sección Look and Feel (una imagen vale más que mil palabras ;-) . Téngase en cuenta, que en la parte inferior de esta pantalla (aunque no aparezca en la pantalla capturada) se da la opción de utilizar la Hoja de Estilos CSS por defecto de MOSS, o bien especificar la URL de la Hoja de Estilos CSS que se desea utilizar.

    Para quién desee curiosear, es posible descargar Páginas Maestras (Master Pages) de ejemplo desde la Web de Microsoft. En cualquier caso, es posible crear o personalizar nuestras propias Páginas Maestras (Master Pages) utilizando SharePoint Designer 2007 o Visual Studio.

    Páginas de Contenido (Content Pages)

    Cualquier Página Web creada en MOSS, tanto una Página Básica (Basic Page), una Página de Web Parts (Web Part Page), como una Página de Publicación (Publishing Page), es una Página de Contenido (Content Page). Esto quiere decir, cualquiera de estas páginas, tiene asociada una Página Maestra (Master Page) de la cual hereda su aspecto. En cualquier caso, una Página de Contenido (Content Page) es un concepto de ASP.Net (ya comentamos que MOSS ó WSS3 no son más que una Aplicación ASP.Net), un tipo de página especial que almacena sólo un contenido Web (código HTML, JavaScript, etc.), debiendo asociarse con una Página Maestra (Master Page), para poder mostrarse como una página Web completa.

    En cualquier caso, cualquier Página Contenido, debe almacenarse en una Librería de Documentos, ya sea en una Librería de Documentos creada por nosotros o creada por el sistema (por ejemplo, como ocurre al activar la característica Office SharePoint Server Publishing y utilizar Páginas de Publicación).

    Una de las principales tareas a realizar con las Páginas de Contenido, es modificarlas. A este respecto, tenemos principalmente dos alternativas: modificarlas utilizando el interfaz Web de SharePoint (la opción Edit Page del menú Site Actions) o bien modificarlas utilizando SharePoint Designer 2007.

    Páginas Plantilla (Layout Pages) y Páginas de Publicación (Publishing Page)

    Es posible crear una Página Plantilla (Layout Page) en MOSS, de tal modo, que al crear una nueva Página de Publicación (Publishing Page, es decir, teniendo la característica Office SharePoint Server Publishing activada) sea posible utilizar como punto de partida la Página Plantilla que hemos creado. Al margen de que podamos crear nuevas Páginas Plantilla (Layout Pages), al activar la característica Office SharePoint Server Publishing se incluyen varias Páginas Plantilla (Layout Pages) por defecto (Article Page, Welcome Page y Redirect Page).

    Pero ¿Qué son las Páginas de Publicación (Publishing Pages)? Antes de continuar, es interesante introducir las Páginas de Publicación (Publishing Pages). Este tipo de páginas, están disponibles después de activar la característica Office SharePoint Server Publishing, y tienen de particular, que se crean a partir de una Página Plantilla (Layout Page), y que se almacenan en una Librería de Documentos especial, creada por el sistema durante la activación de la característica Office SharePoint Server Publishing. Por defecto, en un sitio en inglés, esta Librería de Documento se llamará Pages.

    Las Páginas Plantillas (Layout Pages) de MOSS, se apoyan principalmente en Tipos de Contenido (Content Types) de MOSS y columnas de Sitio. Así, es posible crear una Página Plantilla (Layout Pages) utilizando ciertas columnas incluidas en el Tipo de Contenido asociado a dicha Página Plantilla (Layout Page), y utilizar dichos tipos de contenido en la Página Plantilla (Layout Page), pudiendo personalizar el diseño de la Página Plantilla (Layout Page) con SharePoint Designer 2007. Es decir, la Página Plantilla (Layout Page) es un diseño de página asociado a unos valores, y dichos valores, están almacenados en la Librería de Páginas, como columnas (de ahí el porqué de crear Tipos de Contenido). Con esto, es posible crear una Página de Publicación (Publishing Page) basada en una Página Plantilla (Layout Page), de tal modo que cuando se visualiza la Página de Publicación (Publishing Page), se muestra la Página Plantilla (Layout Page) utilizada con los datos asociados (que se toman de las correspondientes columnas de la Librería de Páginas).

    Para mayor claridad, a continuación se muestra una pantalla capturada de los Tipos de Contenido (Content Types) y columnas utilizadas por la Librería de Páginas de MOSS 2007 (la Librería Pages):

    Dicho todo esto, los pasos que se deben seguir para crear un Tipo de Contenido son los siguientes:

    • Definir Columnas de Sitio. Si las Columnas de Sitios, disponibles desde la opción Site Columns de la sección Galleries en la configuración del Sitio (Site Settings), no son suficientes, podemos crear nuevas Columnas de Sitio conforme a nuestros requisitos.
    • Definir un Tipo de Contenido (Content Type). Un Tipo de Contenido (Content Type) es una colección de columnas y otros objetos de SharePoint. Para poder crear una Página Plantilla (Layout Page), es necesario crear un nuevo Tipo de Contenido (Content Type) que herede del Tipo de Contenido Page.
    • Crear una Página Plantilla (Layout Page). Esta tarea la realizaremos desde la opción Master Pages and Page Layouts de la sección Galleries en la configuración del Sitio (Site Settings). Deberemos especificar el Tipo de Contenido al que queremos asociar la Página Plantilla que estamos creando.
    • Editar la Página Plantilla (Layout Page) en SharePoint Designer. Una vez creada la Página Plantilla (Layout Page), es posible modificarla desde SharePoint Designer 2007 para personalizarla conforme a nuestros requisitos.
    • Publicar y Aprobar la nueva Página Plantilla (Layout Page). Una vez hemos creado y personalizado nuestra Página Plantilla (Layout Page), es necesario Publicarla y Aprobarla, para que esté disponible.
    • Crear una nueva Página de Publicación (Publishing Page) utilizando la Página Plantilla (Layout Page) recién creada. No necesita gran explicación. Es suficiente con utilizar la opción Create Page del menú Site Actions.

    Estos pasos los encontré leyendo el artículo Creating New Page Layouts in SharePoint 2007, y la verdad, me fue de gran ayuda en su momento. Por último, recordar que una Página Plantilla (Layout Page) puede contener Hojas de Estilo CSS, Controles de Servidor, Web Parts, Zonas de Web Parts, etc.

    Hojas de Estilo CSS (Cascading Style Sheet)

    Una Hoja de Estilo CSS es un fichero que permite definir ciertas condiciones de diseño a un código HTML. De este modo, es posible utilizar una única Hoja de Estilos CSS vinculada a múltiples páginas Web, facilitando así la reutilización de esta configuración de diseño, así como la homogenización del aspecto gráfico de todas estas páginas Web. Del mismo modo, al cambiar la Hoja de Estilos CSS por otra, podemos cambiar de forma instantánea el aspecto de las páginas que la utilizan (colores, tipos de fuente, etc.).

    Podemos encontrar las Hojas de Estilo CSS por defecto de MOSS en la ubicación C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033\STYLES. Del mismo modo, podemos encontrar Hojas de Estilo CSS adicionales en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PublishingLayouts\en-us.

    Controles de Campo (Field Controls)

    Los Controles de Campo (Field Controls) son parte de las Páginas Plantilla (Layout Pages). Consisten en simples controles ASP.Net 2.0 enlazados a datos de WSS3. Utilizan un poco de código para poder mostrarse en sus dos modos: tiempo de ejecución (render time) y tiempo de edición (edit time). Existen varios Controles de Campo (Field Controls) incluidos por defecto en MOSS.

    Todos los Controles de Campo (Field Control) de MOSS 2007 se derivan de la clase base FormComponent, aunque es posible derivar de la clase BaseRichField para escribir nuevos Controles de Campo (evidentemente, BaseRichField hereda de FormComponent).

    [Fecha artículo: 24/08/2009]
    [Estado artículo: Cerrado]
    [Autor: GuilleSQL]

    Click on pen to Use a Highlighter on this page
    Tagged with:
     

    Skype Online Status 

    Contáctanos por Skype Call me! - Rolando Escobar: Offline
    » Get Skype, call free! Servicios en Línea
     
     
    Servicios Interdata Ltda. Colaboración e Inteligencia de Negocios, SQL Server 2008, Analysis Services, SharePoint, Excel Services, Reporting Services

    Switch to our mobile site