Uno de los aspectos más cómodos de Velneo para los programadores es la sencillez con la que declaramos en un objeto de lista como una rejilla o grid cuáles serán los formularios de alta, baja y modificación.
Podemos no declarar ninguno, declararlos todos o declarar solo algunos según nuestras necesidades funcionales. Por ejemplo, no poner el formulario de alta si no queremos que el usuario pueda añadir registros, o no declarar el de baja si no queremos permitir al usuario eliminarlos.
La cuestión que en algunos casos nos podemos plantear es ¿Uso el mismo formulario para las tres operaciones o creo formularios diferentes? ¿Qué ventajas o inconvenientes tiene hacerlo de una u otra forma?
Un formulario para todo
Ventajas
- Desarrollo más rápido, solo tengo que crear un objeto.
- Mantenimiento más rápido y seguro, solo tengo que mantener un objeto.
- La aplicación es más ligera, al contener un menor número de objetos.
Inconvenientes
- El usuario no sabe cuando está en baja o modificación.
- Requiere condicionar el botón de eliminar para que solo se vea si el registro ya existe.
Un formulario para cada operación
Ventajas
- Pueden mostrarse datos diferentes en cada circunstancia.
- En altas se pueden pedir solo los datos obligatorios o necesarios.
- Se puede homogeneizar el formulario de baja para que se muestre como un mensaje especial con su icono específico.
Inconvenientes
- Requiere mayor esfuerzo para desarrollar más objetos, aunque se pueden copiar.
- Requiere más mantenimiento, cualquier cambio a nivel de base de datos o interfaz puede requerir mayor número de objetos a modificar.
- La aplicación será más pesada al contener más número de objetos.
¿Cómo valorarlo?
Lo que debemos tener claro es que hacerlo de una u otra forma no implica programar bien o mal. Cada caso puede requerir seguir un criterio más favorable.
Pensando en el usuario es conveniente tener un criterio homogéneo en nuestra aplicación y que toda la funcionalidad sea similar, aunque podemos aplicar excepciones para casos excepcionales.
Como programadores es muy importante tener claro el criterio que aplicaremos a toda la aplicación desde el día 1. Por eso es normal que cada desarrollador o empresa de desarrollo tenga sus propias plantillas para el desarrollo de formularios.
¿Mi opinión?
Le doy mucha importancia a la mantenibilidad de las aplicaciones, por ese motivo prefiero usar el criterio del mismo formulario para altas, bajas y modificaciones como criterio general.
Sin embargo, para casos concretos que suelen coincidir con las tablas más importantes y de más uso de la aplicación prefiero poner formularios de alta diseñados especialmente para conseguir la mejor experiencia de usuario, incluso utilizando en algunos casos formularios de alta de tipo wizard o asistente.
Para los formularios de baja prefiero que sea el mismo que el de modificación porque el usuario puede necesitar ver los datos del registro que está borrando para asegurarse de que es el correcto a eliminar.
¿Te falta alguna ventaja o inconveniente?
Deja un comentario y colabora. Gracias por tu participación.
Hola Jesús.
Primero darte las gracias por retomar el blog y deleitarnos con nuevos «artículos técnicos sobre la herramienta», que viniendo de un responsable directo de Velneo, le dan un gran valor añadido.
En cuanto al tema de unificar formularios, también pienso que depende de cada caso.
Para tablas auxiliares, tablas de maestros o históricos sencillos la unificación de los formularios ABM es viable casi siempre.
Para procesos de negocio más complejos, evidentemente unificar va a ser más dificil.
Yo particularmente uso siempre que puedo formularios unificados. En el manejador PRE_INI detecto si el registro es nuevo (Alta) y en ese caso inicio un asistente que inicializa algunos campos y si es necesario pide datos al usuario mediante ventanas modales.
Hubo una incidencia (grave) con las ventanas modales y mensajes en los PRE_INI y POS_INI de los formularios que ha sido solucionada, por fin, en la versión 21.
Esta incidencia me hizo dudar de si ¿ era buena práctica de programación el mostrar ventanas modales y mensajes en un evento PRE_INI ?. En cualquier caso, tuve que cambiar el diseño hasta ver solucionada la incidencia.
Saludos
Paco Satué
Formularios de Alta, Modificación y Baja; y ¿el de Consulta? Cada rejilla lleva a cada uno de los mencionados pero sería bueno que existiese uno para usuarios que solo pueden consultar. ¿Cómo se manejaría dicha situación?
Hola Zenón.
Un formulario en modo consulta es un formulario cuyos controles de edición están deshabilitados por aplicar permisos o porque quieras que el usuario pulse un botón para habilitar la edición. En cualquier caso una solución muy práctica la encontrarás en estos dos artículos:
Deshabilitar controles de formulario con CSS en Velneo
Deshabilitar controles de formulario con el API de Velneo
Además, el objeto formulario tiene una propiedad condición de activo, que es una fórmula con la que puedes desactivar los controles en función de permisos o de tipo de uso con el que abres el formulario.
Espero que te ayude.
Un cordial saludo,
Jesús Arboleya
Hola Jesús.
Lo primero quiero agradecerte tus consejos y recomendaciones, hace apenas dos meses que empecé a trabajar con Velneo y tanto tu blog como tu podcast me están siendo muy útiles.
Respecto a la opción de usar el mismo formulario para altas, modificaciones y bajas es algo que me sorprendió y que ya consulté a soporte. Se me hace extraño que, tanto si el usuario final pincha en el botón “Modificar” como si pincha en el botón “Eliminar”, se le muestre el mismo formulario con los mismos botones “Eliminar”, “Aceptar” y “Cancelar”.
Es una pena que en el PRE_INI del formulario no podamos saber (a través de una propiedad, variable, etc) desde donde fue llamado dicho formulario, ya que ser esto posible, sería muy fácil controlar la condición de visible de los botones “Eliminar”, “Aceptar” y “Cancelar”.
Un saludo!!