Fabiana Aragón: Informática e Internet

Sharepoint 2007 - Link to Multiple Document Libraries

Sun, 03 Aug 2008 00:15:22 GMT

Hasta el momento fue poco y nada lo que ví sobre Sharepoint... y lo cierto es que ahora que me ví en la necesidad de investigar un poquito más sobre el tema resultó interesándome bastante

Necesitaba agregar un link dentro de una Document Library que apuntara a otra Document Library ubicada en un subsite. Bueno, estuve probando algunas cosas y lo primero que encontré fue agregar una web part de sharepoint. Se trata de una web part especial para links. Cuando lo probé y funcionó dije: "Listo! Problema resuelto!". Jaja pero no era taaan así porque al poco tiempo me dí cuenta de que si bien esto resolvía en cierta forma mi problema, no era del todo lo que quería ya que al haber agregado esta web part las subcarpetas de esa librería heredaban esta web part lo cual no era lo que yo quería. Intenté buscar una forma rápida de quitar esta herencia de modo que la web part solo apareciera en la carpeta principal pero no tuve éxito... al menos no encontré una solución rápida

Finalmente encontré otra forma de agregar estos links y se resolvió el problema. He aquí la solución

En Sharepoint 2007 existe un nuevo concepto de "Content Types". Un content type es algo así como un template para tipos de documentos que uno almacena en las librerías de documentos. En este caso nos concentraremos en el content type para "Document Link". Este se puede usar para crear un link a un documento ubicado en otra librería o a una URL cualquiera. Aquí va el paso a paso de cómo hacer esto:

Observemos las opciones disponibles al momento de crear un nuevo documento en una Document Library de un Team Site estándar.

Ahora vamos a agregar aquí otra opción para el link. Hacemos un click sobre Document Library Settings. Necesitamos acceder a la las opciones avanzadas de la librería así que seleccionamos la opción Advanced Settings.

Dado que necesitamos agregar un nuevo content type, debemos hacer click en Yes al lado de Allow management of content types. Luego click OK.

Al volver a Document Library Settings vemos que ahora tenemos una nueva sección denominada Content Types. Aquí hacemos click en Add from existing site content types.

El content type que necesitamos agregar es un link a un documento así q seleccionamos esa opción en el menú y luego hacemos click en Add para agregarlo. Luego click en Ok.

Ahora deberiamos ver nuestro nuevo content type en Document Library Settings.

Debemos asegurarnos de que se encuentre visible en el nuevo botón.

En adelante cuendo creemos un nuevo documento en esa librería tendremos otra opción debajo de New. Vamos a verificar que se encuentre la opción Link to a Document.

Ahora elegimos esta nueva opción para crear el link. En Document Name escribimos el texto que mostrará este link y en Document URL la URL en donde se encuentra el documento al cual queremos linkear. En el ejemplo queremos linkear un documento ubicado en otra librería pero también podemos colocar aquí cualquier URL dado que Sharepoint no verifica si se está apuntando a otro sitio de Sharepoint.

Y así es como debería verse todo una vez que hayamos terminado:

Bueno espero este post les sea útil... Hasta la próxima!

F.A.

Visual Studio Team System seguro???

Fri, 13 Apr 2007 20:23:07 GMT

Quisiera poder decir que lo es pero desafortunadamente hoy mi experiencia me confirmó que no podemos confiarnos del todo y simplemente al final del día hacer check-in e ir a casa tranquilos pensando que nuestra producción de esa jornada está a salvo. En los meses que llevo trabajando sobre esta plataforma me pasaron cosas muy curiosas, desde que te pida hacer check-out de un archivo cuando solamente querés verlo, pasando por que los formularios en modo diseño a veces no se pueden ver, que cuando cancelas el check-out o cuando haces un Get Latest Version (GLV) se te cierra el Visual Studio y quizás hasta entonces lo más grave que podía pasar era que no te suba al Source Control los archivos nuevos agregados al proyecto pero nunca, NUNCA que no me tome los cambios realizados a un archivo ya existente en el proyecto. Eso fue lo que me pasó hoy, un poco antes de cerrar todo para irme a casa me dí cuenta de que había perdido el trabajo de dos días. Por alguna razón (y que me encantaría saber cual es) no me tomó algunos cambios que hice al subir los archivos al Source Control. Extraño no? Pero es cierto, algunos archivos reflejan perfectamente los cambios y otros no! Cómo puede ser posible que no me tome alguno de los tantos check-in que hago al día? Sí, al igual que todos, siempre que veo hay un avance considerable y tengo una versión funcional subo los cambios y además sabiendo que no soy sólo yo quien trabaja en el mismo proyecto me aseguro de que no hayan quedado archivos sin subir para evitar que mis compañeros tengan errores al momento de compilar: espero a que salga el cartelito que dice que los cambios fueron guardados con éxito y después reviso si queda alguna cosa pendiente a subir (por las dudas…). En fin, toooodo esto lo hice ayer y hoy pero esta tarde me dí con la sorpresa de que algunos de mis cambios ni siquiera están en el Historial! Cosas de Mandrake! Ahora por hacer un GLV se pisaron mis archivos locales y no tengo forma de recuperar el trabajo. Corrí a preguntar a quienes saben mucho de este tema y quizás tenían alguna solución pero lamentablemente la única explicación a esto es que no me tomó bien los check-in y no hay forma alguna de recuperar algo ya que tampoco estas modificaciones están en las máquinas de mis compañeros . Ni siquiera los back-ups que hago me pueden salvar de tener que sentarme este finde a reescribir el código porque hago respaldos semanales y los hago los viernes! El problema me ganó de mano y saltó antes de hacer el back-up. En fin, tendré que recuperar el trabajo este fin de semana pero eso sí otra vez no me pasa! Ahora pecaré por ser exagerada pero voy a hacerme back-ups SIEMPRE antes de hacer un GLV. Bueno, como consuelo trato de sacar lo bueno de esto y es que peor hubiese sido si en lugar de dos días era mucho más, pero sobre todo la experiencia que voy adquiriendo me sirve mucho porque en adelante el Team System no me va a hacer una más de estas . Y bueno, para quienes lean este post espero que les sirva para evitarse futuros dolores de cabeza.

Buen finde para todos!!!

F.A.

Qué es el CAB?

Mon, 13 Nov 2006 18:32:09 GMT

Para cumplir con lo prometido en el primer post explicaré de qué se trata el CAB y para qué sirve. El CAB (Composite UI Application Block) permite construir complejas aplicaciones basadas en Windows Forms. Provee una arquitectura e implementación que hace uso de patrones. Entre los beneficios de construir una aplicación haciendo uso del CAB podemos nombrar: calidad y consistencia para los equipos de arquitectura, el aumento de productividad y tiempos más rápidos de ramp-up para equipos de grandes desarrollos, y consolidación de los esfuerzos operacionales para equipos operacionales.

El CAB está diseñado para apoyar al desarrollo de aplicaciones de cliente inteligente de la línea de negocios, tales como aquellas utilizadas en escenarios de: Procesamiento transaccional de front-ends, Portales de rich client, y Aplicaciones de soporte exclusivo del information worker (tales como aquellas utilizadas en los call centers).

Es importante aclarar que no se debe entender al CAB como un reemplazo del UIProcess, sino como una gran arquitectura de la que puede convertirse parte el UIProcess en versiones posteriores del application block.

Uno de los puntos clave de diseño del Composite UI Application Block es dar soporte al desarrollo de aplicaciones a través del uso de módulos independientes pero que colaboran entre sí. Las aplicaciones que hacen uso del CAB incluyen algunos de estos componentes:

SmartParts: proveen los elementos visuales en las aplicaciones.
Workspace: es el contenedor y administrador de una SmartPart. Puede controlar cómo se visualiza o se oculta la SmartPart y el lugar en donde se ubica. Existen cinco tipos de Workspace: el WindowWorkspace que permite mostrar y ocultar controles ubicados en una ventana, el MdiWorkspace que permite mostrar y ocultar controles y SmartParts en formularios MDI, el TabWorkspace que permite mostrar y ocultar controles y SmartParts dentro de tabbed pages, el DeckWorkspace permite mostrar y ocultar controles y SmartParts de una manera superpuesta sin un frame, y finalmente el ZoneWorkspace que permite crear un Workspace con la capacidad de definir zonas en las que se ubicarán las diferentes SmartParts (Un ejemplo claro de este tipo de Workspace sería una interface al estilo del Outlook).
WorkItems: es un contenedor de componentes que colaboran para completar un caso de uso en tiempo de ejecución. Un WorkItem contiene código start-up que inicializa el caso de uso, un state que es compartido por los componentes que colaboran en el caso de uso, clases controller que actúan sobre el estado y sobre otros recursos, clases view que interactúan con sus controllers y el state de referencia, y por último, código Tear-down.
Infrastructure Services: El CAB incluye un conjunto de servicios básicos de infraestructura que se pueden usa en las aplicaciones. También se pueden construir servicios propios para proveer capacidades específicas para la infraestructura de las aplicaciones. Los servicios que ofrece el CAB son: Catalog Reader service, Module Loader service, Authentication service y State Persistence service.
Modules: se componen de un set de servicios, WorkItems, Smartparts, controllers, entidades de negocio y la clase Module Initialization que se usa para inicializar y correr los WorkItems del módulo.
Module Services: son objetos que se pueden registrar al usar el atributo Service, y después referenciarlos desde cualquier otro componente sin ningún WorkItem.
State: Un WorkItem contiene un estado, el cual es una colección débilmente tipificada de objetos compartidos por los componentes colaboradores de un caso de uso. El State puede persistir llamando a los métodos Load y Save del WorkItem.
Constrollers: Los controllers tienen el mismo rol que en el patrón MVC. Permiten implementar la lógica de negocio detrás de la vista.
Service Agents: son componentes usados para interactuar con cualquier servicio externo de back-end. Los Service Agents son necesarios cuando se desarrollan aplicaciones que usan servicios externos.

El CAB consiste de un número de subsistemas que interactúan para proveer la funcionalidad que el Application Block provee. Cada uno de estos subsistemas se define en su propio namespace y assembly, como se muestra en la figura.

Los assemblies que se usan en una implementación típica del CAB son: Microsoft.Practices.CompositeUI.WinForms.dll, Microsoft.Practices.CompositeUI.dll, Microsoft.Practices.ObjectBuilder.dll

F.A.