Artículo: Una alternativa a los perfiles II »
JUAN RUIZ FERNANDEZ - SEP 30, 2006 (02:37:57 PM)
- El formulario de Ajustes
- Las vistas
- Creando estructuras dinámicas de ajustes
- Posibles mejoras
- Sobre Jonathan Coombs
Por Jonathan Coombs
Nivel : Intermedio
Funciona con : Designer 5.0
Actualizado : 2 Julio de 2001
El formulario de Ajustes
La versión básica del formulario de Ajustes permite a cualquiera con el acceso de Editor a crear, nombrar, y categorizar ajustes que pueden ser guardados como valores de texto o listas de texto. Tambien facilita un campo de instrucciones para almacenar una explicación para cada ajuste. Echemos una mirada más cercana a cada uno de estos campos ( como los mostrados en la figura de más abajo ).
El campo oculto fDocType siempre calcula a "Setting" y es utilizado por las fórmulas de selección de las vistas de Ajustes. ( Usar un campo personalizado nos proveerá de una mayor flexibilidad a largo plazo que usar el campo Form ).
El campo Categories no debe tener el prefijo f porque su nombre tiene un significado especial para Notes. Los usuarios pueden categorizar documentos de Ajuste individuales escribiendo un título de categoría en este campo, o ( en Notes ) ellos pueden categorizar varios documentos a la vez seleccionando Categorizar desde el menú de Acciones. ( Tener en cuenta que los campos Categories deben ajustarse para permitir múltiples valores, dado que la característica Categorizar devuelve una lista de texto ).
Los campos fName, fValue y fInstructions son todos campos de texto de único valor, de esta forma Domino automáticamente los envía al cliente Web usando las etiquetas <INPUT> de HTML. Eso es adecuado para el campo corto fName, pero los campos fValue y fInstructions necesitan dar soporte a múltiples líneas de texto. Así, los campos fValue y fInstructions son sólo enviados al cliente Web cuando estamos en modo lectura. Cuando editamos desde la Web, los campos para visualizar fdValueWeb y fdInstructionsWeb son utilizados, en cambio. Sus fórmulas generan campos HTML <TEXTAREA> de nombre fValue y fInstructions, respectivamente, de forma que esos valores de las areas de texto son salvadas de vuelta en sus propios campos Notes al submitir.
Hay pocas cosas que podamos hacer cuando usamos esta técnica. No puede ser utilizada si la propiedad del formulario "Generar HTML para todos los campos" está activada, porque esta generará nombres de campo duplicados en la página. Además, los caracteres de nueva línea devueltos por el navegador pueden no ser interpretados correctamente por Notes. Los caracteres ASCII 13 y 10 son utilizados para indicar retornos de carro y saltos de línea, pero no siempre son utilizados de forma consistente. En los navegadores que he testeado, un 13 seguido de un 10 es equivalente a una @NewLine en Notes, y entonces cualquier 13 o 10 individual es tambien equivalente a una nueva linea. De esta forma, he añadido estas fórmulas de traducción a los campos fValue y fInstructions, respectivamente :
@ReplaceSubstring(fValue; (@Char(13)+@Char(10)):@Char(13):@Char(10);@NewLine) @ReplaceSubstring(fInstructions; (@Char(13)+@Char(10)):@Char(13):@Char(10);@NewLine)
El campo siguiente, fValues, es un campo de texto multivalor fijado para mostrar los valores múltiples en líneas separadas, de forma que Domino automáticamente genera un campo <TEXTAREA> para ello y maneja cualquier carácter de nueva línea apropiadamente. Este campo de area de texto, así, no requiere un campo para visualizar especial o fórmula de translación.
El campo oculto fValueString almacena cada valor de ajuste en un formato estándar alternativo. Primero determina si el valor de ajuste fue introducido en fValue o fValues, y entonces convierte el valor en una cadena estándar :
@If(fValue != "";fValue;@Implode(fValues;@NewLine))
Finalmente, el campo oculto $$Return indica a Domino que muestre la vista de Ajustes despues de que el formulario Web ha sido submitido.
path := @ReplaceSubstring(@Subset(@DbName;-1);"\\";"/"); "[/" + path + "/" + "vwSetting" + "]"
Además de todos estos campos, el formulario Settings (Ajustes) incluye un conjunto estándar de acciones : Modo Edicion, Modo Lectura, Salvar & Cerrar, Cancelar y Borrar. Para hacer el diseño del formulario parecer un poco mejor desde la web, tambien he añadido una etiqueta <P> debajo del título como texto HTML y utilizado los atributos HTML de los campos para fijar sus alturas. Puedes desear hacer otros cambios cosméticos tambien, pero ten siempre en cuenta que el formulario debería ser tan genérico y reutilizable como sea posible.
Las vistas
Las vistas ( vwSettings y vwLookSettings ) nos proveen del acceso a los documentos de Ajuste para ver, editar y búsquedas por código. Esta funcionalidad podría ser combinada en una vista única, pero en vez de eso he creado un interfaz de vista para un usuario, la vista Ajustes mostrada arriba, para ver/editar y una vista oculta para búsquedas por codigo, mostrada abajo. Esta es un estandar de diseño extremadamente importante porque nos permite retocar libremente nuestro interfaz de usuario para vistas para que se ajuste a las necesidades de los usuarios sin tener que romper ninguna búsqueda por código.
Las vistas están documentadas con sentencias REM en sus fórmulas de selección, pero echémosles un rápido vistazo.
Como mencioné antes, ambas vistas seleccionan sólo aquellos documentos cuyo campo fDocType es igual a "Settings". La vista de Ajustes ( Settings ) es una vista categorizada y con formato que contiene acciones que el usuario puede seleccionar, mientras que la vista de Búsquedas está completamente sin formato y muestra solo una única clave para cada documento. Fue diseñada para soportar las búsquedas de LotusScript y las búsquedas de fórmula por nombre de campo. No tiene columnas para fValue o fValues porque las búsquedas que están hechas contra números de columnas tienden a hacer el diseño de la vista menos flexible ( y el código de las búsquedas menos legible ). Aun así, si encuentras que tu aplicación requiere búsquedas más rápidas, podría ser necesario añadir columnas de búsqueda.
Desde que cada ajuste es únicamente identificado por la combinación de su categoría y nombre, la vista de búsquedas define su clave de búsqueda como la concatenación de las dos, separadas por un asterisco (*). El formulario de Pedidos (Order) ejecuta tres búsquedas contra esta vista oculta, una para el campo de instrucciones y una para cada uno de sus campos de opciones excluyentes ( radio button ). Ya que el campo de instrucciones necesita el valor de texto único almacenado en el ajuste "Examples\01\Instructions", su clave es b>"Examples\\01*Instructions" y accede el campo fValue :
key := "Examples\\01*Instructions"; temp := @DbLookup( "Notes":"NoCache";"";"vwLookSettings";key;"fValue" ); @If( @IsError(temp);"Error: Unable to find the Setting document (" + key + ")";temp)
Las búsquedas para los dos campos de opciones excluyentes ( radio button ) son idénticas, excepto que tienen sus propias claves únicas y recuperan sus valores del campo fValues.
Creando estructuras dinámicas de ajustes
Para demostrar la flexibilidad ganada por el uso de un formulario genérico y un documento por ajuste, la base de datos de ejemplo incluye un formulario de Peticiones Avanzado. Este formulario contiene un número variable de ajustes almacenados en una jerarquía simple.
El formulario original de Peticiones mostraba todos sus items en una lista larga. El formulario de Peticiones Avanzado nos provee de los mismos items, pero los divide en categorías.
La lista de categorías es mantenida en el ajuste "Examples\02\Items\Categories" y mostrada en el campo Categoria. Siempre que su valor cambie, este campo actualiza el formulario, causando que el campo de selección de items muestre la lista de items que corresponden a la categoría. La búsqueda que devuelve esta lista es muy similar a la que se usó en el formulario Peticiones original, excepto que ésta usa la categoría actual como parte de su clave de búsqueda :
key := "Examples\\02\\Items*" + fItemCategory; temp := @DbLookup("Notes":"NoCache";"";"vwLookSettings";key;"fValues"); @if( @IsError(temp);"Error: Unable to find the Setting document (" + key + ")";temp)
Para soportar esta asociación dinámica de categorías e items, he dividido el documento de Ajustes ( Settings ) original ( "Examples\01\Items" ) en múltiples documentos. Actualmente hay cuatro categorías, pero el formulario de Peticiones ( Order ) permitirá cualquier número de categorías sin un cambio de diseño, tantos como aquellos que correspondan a un valor en el ajuste "Examples\02\Items\Categories". Cada categoría listada en el formulario de Peticiones Avanzado tiene su correspondiente documento de ajuste, como se puede ver en la vista de Ajustes de abajo.
Posibles mejoras
Este artículo ha presentado la estructura básica de una herramienta de Aplicación de Ajustes reutilizable y unos pocos ejemplos de cómo puede ser utilizada con Notes y Domino para mantener ajustes individuales, un número variable de ajustes, o una jerarquía estructurada de ajustes. El interfaz de usuario para esta herramienta no es sofisticado, pero es normalmente adecuado para aplicaciones que requieran un pequeño mantenimiento y tenga administradores bien entrenados.
El problema más significativo con el formulario de Ajustes Básico es su interfaz simple. No soporta directamente tipos de datos que no sean de texto, de forma que las fechas, los nombres, y los números tienes que ser introducidos como cadenas sin validar. Tambien es de alguna forma confuso porque no distingue entre desarrolladores y administradores de la aplicación. Esto es, cualquiera con acceso de Editor tiene acceso completo a cada ajuste, aunque en la mayoría de los casos, el administrador solo editará el campo de Valor o Lista de Valores ( pero no ambos ). Un diseño que diera acceso completo sólo a los desarrolladores sería más seguro. Puedes tratar estos y muchas otros asuntos mejorando la herramienta Aplicación de Ajustes.
Estos y muchos otros asuntos pueden ser tratados mejorando la herramienta Aplicación de Ajustes. He empezado este proceso creando un formulario de Ajustes Avanzados que soporta múltiples tipos de datos, implementa roles de usuario, y mejora el interfaz de usuario. Tambien provee de una librería de scripts que simplifica las búsquedas LotusScript. Esta versión mejorada de la herramienta Aplicación de Ajustes, Base de datos de ejemplo de Ajustes Avanzado, está disponible en el Iris Sandbox y se describe en el artículo de Iris Today "Desarrollando una herramienta de ajustes avanzada"
Sobre Jonathan Coombs
Jonathan es un desarrollador de software de la empresa Joseph Graves Associates. Inc. en Indianápolis. JGA es una firma consultora de servicios completos que provee de servicios de calidad en TI y comercio electrónico a la medida, Internet, y soluciones de software para la gestión documental. Los intereses profesionales de Jonathan incluyen la reutilización del software, la tecnología Lotus Notes y Domino, y la lingüística computacional. Puedes contactarcon el en la dirección jonathancoombs@bigfoot.com
