• Introducción
• Alternativas de diseño
• Una implementación básica
• Estandares de diseño del formulario de Ajustes

---

Por Jonathan Coombs
Nivel : Intermedio
Funciona con : Designer 5.0
Actualizado : 2 Julio de 2001

---

Introducción

En el proceso de desarrollar una aplicación, casi siempre identificas ciertas características del sistema que necesitan tener una funcionalidad configurable. Por ejemplo, el dueño de la aplicación puede necesitar ser capaz de modificar la lista de opciones mostradas en un combo de un formulario. O el texto de todos los correos electrónicos generados por el sistema pueden necesitar ser periódicamente actualizados para reflejar los cambios en la política corporativa.

En algunos entornos Notes, el desarrollador de cada aplicación es responsable de hacer los cambios directamente a las bases de datos en producción. En estos entorno, podrías ser capaz de cambiar una configuración de la aplicación manualmente haciendo cambios menores del diseño. Sin embargo, en la mayoría de los entornos - y buenas prácticas de desarrollo en general - dictan que el diseño de producción no será modificado frívolamente. En un entorno típico, primero completas una nueva versión de la aplicación en un servidor de desarrollo y entonces pides formalmente a los administradores de Notes que la muevan a producción.

En general, entonces, los cambios de diseño deberán ser utilizados solo para arreglo de errores y mejoras verdaderas, y los ajustes configurables serán modificables a través de un interfaz de "configuración del sistema" o "Ajustes de la aplicación". ( Estas características tambien son llamadas como control, clave o documentos de perfil ). Si este interfaz puede ser hecho amigable para el usuario y robusto, puedes dar a los propietarios de la aplicación la responsabilidad de mantener algunos de estos ajustes. Si este interfaz puede tambien ser hecho genérico y reutilizable, puede incrementar la flexibilidad del sistema y reducir significativamente el tiempo de desarrollo.

Este artículo presenta una herramienta de Ajustes de Aplicación reutilizable en el contexto de una aplicación ficticia de seguimiento de pedidos y cubre unos pocos importantes estándares que incrementan la reusabilidad de la herramienta. Puedes descargar y examinar el ejemplo de la Base de datos Ajustes Simples expuesto en este articulo desde el Sandbox de Iris. Ya que la herramienta de Ajustes de Aplicación soportará tanto el cliente de Notes como el de web, el artículo tambien cubre algunas técnicas básicas para mantener la compatibilidad con ambos.

Este artículo asume un entendimiento intermedio del diseño de aplicaciones Notes/Domino.

Alternativas de diseño

El ejemplo más típico de un interfaz de ajustes de aplicación es un documento único de perfil conteniendo un campo por ajuste. Las instrucciones y tipos de datos para cada campo estan escritas a mano en el diseño del formulario de perfil. Por ejemplo :

Esta aproximación tiene la ventaja de ser simple y centralizada, y el uso de funciones de Notes que facilitan una acceso rápido a los documentos de perfil como @GetProfileField y NotesDatabase.GetProfileDocument.

Hay desventajas, sin embargo, al usar documentos de perfil. La principal desventaja es que son ocultos, siendo difíciles de encontrar, borrar o copiar entre bases de datos ( por ejemplo, de desarrollo a producción ). Es tambien difícil construir un interfaz para ver y mantener múltiples documentos de perfil. Si todos los ajustes de una aplicación tienen que ser guardados en un único documento, es pesado organizar todos esos ajustes de forma entendible en el formulario del documento.

A causa de estos problemas, usualmente evito usar documentos de perfil. En vez de eso, almaceno los ajustes de aplicación en documentos ordinarios de Notes ocultos en una vista administrativa, usando un formulario genérico para crear un documento separado para cada ajuste.

Esta aproximación tiene tambien sus desventajas. Añade un elemento de diseño adicional ( la vista ) y usa funciones de búsqueda indirecta ( @DbLookup y NotesView.GetDocumentByKey ), las cuales pueden impactar negativamente en el rendimiento en algunos casos. Incluso así, la habilidad de crear y mantener cualquier número de ajustes es necesario cuando se construye una herramienta de Ajustes de Aplicación reutilizable, asi que pienso que esta flexibilidad pesa más que las desventajas.

Asi que, ¿Qué aparencia tiene un formulario genérico de Ajustes? El formulario de Ajustes presentado en este artículo es muy simple en concepto. Ya que cada ajuste es almacenado como un documento separado, el formulario esencialmente sólo necesita dos campos : un campo de texto para almacenar el nombre único del ajuste y un campo de texto para almacenar su valor. Pero ¿Porqué parar aquí? Añadiendo un campo para instrucciones, cada ajuste puede ser hecho para mostrar un mensaje explicando su propósito y uso. Añadiendo una campo de Autores nos damos la capacidad de asignar ajustes específicos a administradores específicos. Añadiendo diferentes tipo de campos de valor podemos hacer que el interfaz de usuario soporte varios tipos de datos además del texto simple.

Notad que esta aproximación no está ligada al diseño de ninguna aplicación particular. No pone restricciones sobre el número de ajustes que una aplicación puede tener; la aplicación podría ser diseñada para usar un número variable de ajustes, o incluso jerarquías de ajustes. Una vez la herramienta ha sido desarrollada plenamente y depurada en todos los clientes, puede ser utilizada en una amplia variedad de aplicaciones sin modificar su diseño. Si la herencia a nivel de elemento de diseño se habilita, las correciones de errores y las mejoras pueden ser desplegadas desde una plantilla central. ( Como con cualquier herramienta reutilizable, la entrega y mantenimiento debería ser cuidadosamente planeada. Si eliges no usar la herencia de diseño, ten cuidado de crear una variante diferente de la herramienta para cada aplicación. Mira la ayuda de Domino 5 Designer para saber más sobre herencia de diseño ).

Una implementación básica

Empezemos mirando una implementación básica de la herramienta Ajustes de Aplicación que es plenamente funcional tanto en clientes Notes como de Web y que puede ser facilmente actualizada a una herramienta más avanzada. La herramienta de Ajustes de Aplicación consiste de un formulario, una vista de usuario y una vista oculta de búsqueda. Estos elementos, junto con un formulario de Pedidos y una vista que demuestre su uso, están incluidos en la base de datos Ajustes Simples (SettingsSimple.nsf) disponible en el Sandbox de Iris.

Antes de que examinemos cómo el formulario de Ajustes y las vistas de la herramienta Ajustes de Aplicación son puestas juntas, aquí tenemos una muestra de como la herramienta trabaja con la aplicación de ejemplo de seguimiento de pedidos. El formulario de ejemplo de Pedidos, abajo, demuestra el uso de ajustes de texto y de listas de texto.

Aunque las instrucciones y las opciones de botones de radio podrían ser construidas en el formulario, el formulario será más flexible si los gerentes de la aplicación pueden controlarlos usando documentos de Ajuste.

Para almacenar estas instrucciones y listas de opciones del formulario de Pedidos, la herramienta de Ajustes de Aplicación necesitará guardar un ajuste de texto y dos ajustes de listas de texto. Cada ajuste será individualmente creado con el formulario de Ajustes y almacenado en su propio documento. Por ejemplo, la pantalla de abajo muestra un documento de Ajuste para una de las listas de texto, el campo Aprobado. ( El campo Categoria en este formulario está ahí para ayudar a mantener un gran número de ajustes organizado ).

Esta versión básica del formulario de Ajuste es fácil de implementar y hacen los ajustes de aplicación disponibles para clientes de Notes y, en este caso, clientes Web. El tener un interfaz Web tanto como un interfaz Notes puede no ser necesario si tus administradores de la aplicación pueden acceder a la aplicación sólo con clientes de Notes; pero ya que estamos desarrollando una herramienta que puede ser usada en muchas aplicaciones diferentes, es una buena idea que la herramienta soporte ambos clientes.

Cuando los documentos de Ajuste son creados, aparecen en la vista de Ajustes. La pantalla de abajo muestra la vista de Ajustes con los documentos de Ajuste para los ajustes del formulario de Pedido. Los campos del formulario de Pedido pueden entonces usar comandos @DBLookup para recuperar los ajustes de los documentos de Ajuste. La sintaxis de estos comandos de búsqueda están descritos más tarde en este artículo.

Estandares de diseño del formulario de Ajustes

Antes de explicar el diseño del formulario de Ajustes, echemos una mirada a las convenciones de nombrado y diseño que sigue.

Cerca de la parte de arriba del formulario existe una sección colapsada que contiene documentación embebida de diseño. He incluído documentacion en el propio formulario porque a los desarrolladores les gusta verla ahí y porque va donde quiera que el formulario va. ( Alguna documentación adicional es proporcionada a través de sentencias REM en fórmulas de campos individuales ).

Cada nombre de campo se encuentra precedido con una f, y tambien con una d si es un campo sólo para visualizar. Esto ayuda a distinguirlos de los nombres de campos reservados por Notes para propósitos especiales ( por ejemplo, Form, Server_Name y SendTo ). Los campos ocultos son pequeños ( 8 puntos ) y grises, y usualmente tienen etiquetas en negrita próximos a ellos. ( Cuando desocultamos varios campos ocultos para propósitos de depuración, las etiquetas hacen fácil que nos cuenten cual es cada uno).

Otra consideración importante con cualquier edición en Web de un formulario es el cacheo de la página. La mayoría de los navegadores de los usuarios almacenan las páginas accedidas recientemente en el disco duro local. Esto mejora el rendimiento cuando se navega por páginas estáticas, pero tambien puede prevenir a esos usuarios de ver sus cambios más recientes si editan, salvan y reabren un documento. Para decirle al navegador que siempre pida una pagina actualizada, podemos ajustar el formulario a "Activar modo edición automáticamente", o usar una etiqueta HTML <META> ( en la fórmula del Contenido del encabezado de HTML del formulario ) para dar a la página una fecha de expiración pasada :

"<META HTTP-EQUIV=\"Expires\" CONTENT=\"Mon, 06 Jan 1990 00:00:01 GMT\"></META>"

En breve publicaré la segunda parte de este artículo.

	Artículos
	Publicaciones
	Comentarios