Usar controles de servidor ASP.NET en aplicaciones de elementos Web

Artículo
10/22/2014

Actualización: noviembre 2007

En una aplicación de elementos Web, la interfaz de usuario principal consta de controles de servidor ASP.NET que residen dentro de zonas: regiones de una página Web que tienen una interfaz de usuario común y que están creadas por un tipo de control compuesto derivado de la clase WebPartZoneBase. Las capacidades de estos controles de servidor que forman la interfaz de usuario principal de una aplicación de elementos Web se definen en la clase base WebPart, pero no está limitado a utilizar controles derivados de esta clase. También puede utilizar cualquier control de servidor ASP.NET estándar, cualquier control de usuario o cualquier control de servidor personalizado. En este tema se explican algunos problemas derivados del uso de controles de servidor en aplicaciones de elementos Web cuando los controles no heredan de la clase WebPart.

Crear controles de elementos Web en tiempo de ejecución

Para los diversos tipos de controles de servidor que no heredan de la clase WebPart, el conjunto de controles de elementos Web ofrece un mecanismo que les permite participar en aplicaciones de elementos Web y tener las mismas capacidades que un control que deriva de la clase WebPart. Esto no requiere ninguna acción especial por parte de los desarrolladores; basta con agregar un control de servidor a una zona WebPartZoneBase. Cuando se compila una página Web, cualquier control de servidor que resida en una zona y no herede de la clase WebPart se ajustará automáticamente con una instancia de la clase GenericWebPart y se convierte en un control secundario de dicha instancia. Puesto que la clase GenericWebPart hereda de la clase WebPart, el control de servidor está habilitado ahora con toda la funcionalidad de un control WebPart. En resumen, si se agregan controles de servidor que no heredan de la clase WebPart a una zona WebPartZoneBase, los desarrolladores permiten que los controles se conviertan en controles WebPart en tiempo de ejecución.

Nota:
Del mismo modo en que puede utilizar controles de servidor en aplicaciones de elementos Web, también puede utilizar controles WebPart fuera de aplicaciones de elementos Web. Si agrega un control que hereda de la clase WebPart a una página situada fuera de una zona, funcionará como un control de servidor normal y simplemente perderá sus capacidades de elementos Web.

Agregar controles de servidor ASP.NET a zonas

Cuando agrega controles de servidor ASP.NET, controles de usuario o controles personalizados a una zona WebPartZoneBase, no se necesita ninguna técnica ni declaración especial en la página. Puede agregarlos a una zona de las mismas formas en que agregaría normalmente controles a una página Web: mediante declaración (en el formato de persistencia de página) o mediante programación. Además, puede utilizar la función de catálogo de elementos Web, que le permite agregar controles de servidor a un catálogo en el que los usuarios pueden seleccionar y agregar controles a la página en tiempo de ejecución. Para obtener información detallada, vea los controles DeclarativeCatalogPart y ImportCatalogPart.

Si agrega un control de servidor a una zona mediante programación, el método recomendado consiste en agregarlo utilizando el método AddWebPart del control WebPartManager.

Cuando agrega a una zona mediante declaración controles de servidor que no son controles WebPart, si utiliza una herramienta de diseño visual como Microsoft Visual Studio 2005, no verá las propiedades y los miembros de WebPart en el panel de propiedades ni en IntelliSense. Para obtener detalles, vea la próxima sección en la que se explica cuándo utilizar controles WebPart frente a otros controles de servidor.

Decidir cuándo utilizar las diferentes opciones de controles de servidor

Puede que los desarrolladores se pregunten si, puesto que pueden utilizar cualquier tipo de control de servidor en una aplicación de elementos Web, existe alguna razón para crear un control que se deriva de la clase WebPart. En muchos casos, la opción preferida es utilizar un control de servidor ASP.NET, un control de usuario o un control personalizado, especialmente si los controles ya existen. No se produce ninguna pérdida de funcionalidad de elementos Web en tiempo de ejecución cuando se utilizan estos tipos de controles de servidor y se obtienen muchas ventajas, como la posibilidad de reutilizar código existente, y la posibilidad de aprovechar sus conocimientos sobre desarrollo de controles y aplicarlos a las aplicaciones de elementos Web.

Además, puede hacer que los distintos controles de servidor se comporten de manera idéntica a los verdaderos controles WebPart si implementa varias interfaces que implementa la clase WebPart. He aquí las interfaces que debe conocer.

La interfaz IWebActionable. Si implementa esta interfaz, podrá agregar verbos personalizados (acciones frecuentes que los usuarios pueden realizar sobre un control en la interfaz de usuario, como minimizar, cerrar o modificar) al menú de verbos del control.
La interfaz IWebEditable. Si implementa esta interfaz, podrá asociar controles EditorPart personalizados al control de servidor, lo que permitirá a los usuarios modificar las propiedades personalizadas y el comportamiento especificados del control en tiempo de ejecución.
La interfaz IWebPart. Si implementa esta interfaz, el control tendrá una serie de propiedades de un auténtico control WebPart que se heredan de la clase Part, lo que le aporta la misma apariencia que un control WebPart, incluso en tiempo de diseño.

La ventaja principal de crear un control como un control WebPart es que tiene un control completo sobre su comportamiento específico de elementos Web. Un ejemplo de ello es cuando un desarrollador de controles desea cambiar el comportamiento en tiempo de ejecución de un control y, a continuación, redistribuirlo a los usuarios. Un desarrollador podría reemplazar una de las propiedades virtuales de la clase WebPart, como AllowClose, y convertirla en una propiedad de sólo lectura que siempre devuelva false. Esto impide que se cierre el control y los usuarios del control están limitados a ese comportamiento.

Un segundo ejemplo donde puede beneficiarse de la herencia de la clase WebPart está relacionado con el comportamiento en tiempo de diseño. En un control WebPart, todos los miembros WebPart expuestos son visibles para los desarrolladores de páginas en tiempo de diseño mediante IntelliSense (si utilizan una herramienta de diseño visual como Microsoft Visual Studio 2005), por lo que pueden trabajar con las propiedades en modo declarativo y en el panel Propiedades. Por el contrario, si declara controles de servidor en una zona en tiempo de diseño y no son controles WebPart, no puede ver los miembros que son específicos de la clase WebPart (aunque puede declararlos) en IntelliSense ni en el panel Propiedades. Esto se debe a que, en tiempo de diseño, un control de servidor normal todavía no se ha ajustado con un objeto GenericWebPart, por lo que no tiene las características de WebPart que tendrá en tiempo de ejecución. Si bien puede permitir que los controles de servidor tengan una apariencia similar a la de los controles WebPart y actúen como ellos implementando las interfaces enumeradas anteriormente, suele ser más sencillo crear un control WebPart. Los desarrolladores de controles y los proveedores que crean paquetes de controles pueden beneficiarse del hecho de derivar de la clase WebPart, por lo que pueden ofrecer características más completas en tiempo de diseño para sus controles.

Controles de usuario como controles WebPart

Los controles de usuario son una opción eficaz para los desarrolladores de ASP.NET, ya que les permiten crear rápidamente una interfaz de usuario compleja para el control utilizando la misma sintaxis de declaración que se emplea en las páginas Web, y ofrecen una forma cómoda de dividir y reutilizar código en varias páginas. Al igual que los controles de servidor ASP.NET, los controles de usuario también son una opción excelente para las aplicaciones de elementos Web. Los controles de usuario se pueden agregar directamente a una zona WebPartZoneBase y funcionarán como controles WebPart en tiempo de ejecución, como se ha descrito anteriormente. También pueden utilizarse con la función de catálogo de elementos Web, ya sea como controles que se pueden importar o para empaquetar un conjunto de otros controles de servidor que los usuarios pueden seleccionar y agregar a una página (para obtener más información, vea la propiedad WebPartsListUserControlPath).

Nota importante:
Debe saber que el almacenamiento en caché de resultados de ASP.NET está deshabilitado en los controles de usuario que se utilizan como controles WebPart en tiempo de ejecución. El conjunto de controles de elementos Web requiere que haya un control en el árbol de controles para cada solicitud de una página. Esto es necesario para que funcionen ciertas características de elementos Web como la personalización (para obtener detalles, vea Información general sobre la personalización de elementos Web). En las solicitudes donde se almacena en memoria caché un control de usuario (para obtener detalles, vea la directiva @ OutputCache), no se agrega al árbol de controles. Por esta razón, el almacenamiento en memoria caché de resultados es incompatible con las características de elementos Web, y no funciona con los controles de usuario que funcionan como controles WebPart en una aplicación de elementos Web.

Debe saber que el almacenamiento en caché de resultados de ASP.NET está deshabilitado en los controles de usuario que se utilizan como controles WebPart en tiempo de ejecución. El conjunto de controles de elementos Web requiere que haya un control en el árbol de controles para cada solicitud de una página. Esto es necesario para que funcionen ciertas características de elementos Web como la personalización (para obtener detalles, vea Información general sobre la personalización de elementos Web). En las solicitudes donde se almacena en memoria caché un control de usuario (para obtener detalles, vea la directiva @ OutputCache), no se agrega al árbol de controles. Por esta razón, el almacenamiento en memoria caché de resultados es incompatible con las características de elementos Web, y no funciona con los controles de usuario que funcionan como controles WebPart en una aplicación de elementos Web.