Formularios en SharePoint

Question

Si quiero poner un formulario en SharePoint, ¿es más fácil usar InfoPath o crear un elemento web personalizado en C #? ¿Hay otras opciones que debería considerar?

¿Cuáles son los requisitos y los obstáculos para cada opción?

Answer 1

La creación de formularios mediante InfoPath es la forma más sencilla de publicar un formulario en SharePoint. Tenga en cuenta que tiene muchas limitaciones y es posible que intente poner un poco de lógica problemática o que necesite una característica adicional.

La programación en C # requiere conocimientos de C # (por supuesto) y conocimientos de las API de SharePoint. Además, una vez completado, la DLL resultante debe publicarse y ser de confianza para SharePoint, que requiere la intervención del administrador del sistema. Es posible que esto no siempre esté disponible para usted, y puede ser problemático la próxima vez que intente actualizar SharePoint.

Finalmente, recomiendo tratar de lograr la mayoría de las cosas (incluidos los formularios) simplemente mediante el uso de las funciones integradas de SharePoint. Si te sumerges un poco en él, descubrirás que realmente puedes crear aplicaciones complicadas simplemente personalizando las vistas de Listas, organizando el orden de los campos, agregando columnas (y columnas del sitio) propias, etc. Lo mejor de Este enfoque es el SharePoint puro. No se necesitan conocimientos (y personas) adicionales.

Answer 2

En realidad, no necesitas mucho conocimiento de las API de SharePoint para crear un formulario web personalizado. Es un proceso muy sencillo; No tengo ningún enlace a la mano, pero debería haber más de unos pocos " hola mundo " ejemplos flotando alrededor para empezar. Las partes más complicadas con las partes web de SharePoint es la mejor manera de depurarlas e implementarlas.

Conozco a algunos consultores que tienen un conjunto completo de servidores virtuales que se ejecutan localmente en sus computadoras portátiles para que todo esté allí para que jueguen. Esa no es una opción para mí; mi grupo utiliza System.Web.UI.WebControls.WebParts.WebPart, por lo que podemos realizar pruebas locales antes de implementar en nuestro entorno de desarrollo. Tenga en cuenta que si va por esa ruta, no puede realizar una prueba completa a nivel local, ya que perderá algunos elementos de SharePoint como hojas de estilo y elementos web provistos por el sistema. En cuanto a la implementación, todavía estamos trabajando en los detalles. Puede hacerlo manualmente, pero no es ideal para entornos de producción bloqueados. Un enfoque de revisión es " Características " ;; Parece prometedor para aplicar nuevas mejoras como un solo instalador, aunque no estoy seguro de cómo manejar las correcciones de errores para él.

Answer 3

¿Puede ser más específico sobre la forma y la versión de SharePoint?

Depende de su versión de Sharepoint: si tiene 2003, si desea usar InfoPath, también debe instalarse en los clientes. En SharePoint 2007, creo que no es necesario.

Si es una forma grande con pocas reglas de negocios, InfoPath puede ser el camino a seguir - > wysiwyg, y fácil despliegue.

Si su formulario implica más reglas de negocios, un elemento web o una página en _layouts puede ser " más simple " y más mantenible.

Answer 4

Infopath es perverso al construir rápidamente formas y lanzarlas a Sharepoint. Espero que sea 1000 veces más rápido que compilar una aplicación C # personalizada.

Answer 5

Puede depender de la forma en que pienses

Por ejemplo,  1. Puede optar por Infopath, si está tratando de dar el control al usuario final para que personalice el formulario por cuenta propia.

Infopath es muy fácil de entender, desarrollar. Para poder utilizar el infopath, debe aprender Infopath, Infopath Form Services y Sharepoint api para integrar Dotnet (C #) y Sharepoint.