Actualización de Desarrollo CGI::Application::SqlForms.pm

Wed Sep 24 12:48:49 CDT 2003

Quise darle un título entendible. Este e-mail es una actualización sobre el estado de desarrollo de la librería que les comenté hace un tiempo que quería desarrollar. Como ven ya le escogí un nombre aunque su nombre formal sería CGI::Application::SqlForms ya que heredo de Application. Estuve investigando un tiempo en CPAN para no reinventar la rueda y decidí tomar CGI::Application como base ya que establece una lógica de desarrollo acorde con mis experiencias previas en desarrollos CGI.

Hasta ahora estoy solo en la fase de conceptualización y esto es lo que llevo adelantado. Lo posteo en la lista para escuchar opiniones y sugerencias mientras comienzo el desarrollo del alpha que debe estar listo en unpar de semanas (no porque sea tan lento sino por mi carga habitual de trabajo). Voy a documentar el proyecto en inglés para su fácil publicación y mantenimiento en CPAN aunque me comprometo a una documentación posterior en español.

Hasta ahora solo he diseñado el UI (User Interface) asbtracto y que no depende ni de CGI::Application y mucho menos de CGI. La idea es que la capa de UI esté atada al negocio independientemente de la salida, aunque por supuesto la primera versión será integrada con CGI::Application. La idea es que posteriormente cualquiera pueda substitur CGI::Application por GTK, Tk, o Win32 (ugh!).

Estados de una forma:
=====================

Cada forma tendrá unos estados básicos con respecto a la edición de registros en la BD. Esto es separado por completo del estado y/o el flujo del documento que es un tema aparte y no tocaré en este e-mail. A lo que me refiero aqui es a los estados de la forma que despliega y edita los registro de un RDMBS. 

1) Los _estados_[1] inciales pueden ser ``Search'' e ``Insert''. Es decir que la forma puede entrar en cualquiera de estos dos modos de arranque. 

2) Después del _proceso_[1] de ``Search'' o el proceso de ``Insert'' la forma cae en modo ``View'' | ``Modifiy'', dependiendo si fué una busqueda o una inserción respectivamente. Hay un proceso update asociado al botón por default (en html, el submit button default, o en un GUI lo que esté asociado a la tecla enter) que procesa la forma y detecta cambios en la misma. Los cambios pueden completar valores haciendo consultas a la BD y otros procesos. El proceso de update es basado en el servidor siempre, evitando cualquier procesamiento innecesario en el cliente (evita el uso de JavaScript, por ejemplo y que las aplicaciones corran en Lynx).

3) Se prevee un mecanismo de ``Locking'', nivel aplicación, que es independiente al bloqueo que ofrece el RDBMS. La idea es que el usuario pueda bloquear la edición de un registro y decidir si quiere o nó que otros usuarios vean una copia anterior.

4) Existe un proceso ``Save'' que guarda los cambios en la BD y posiblemente libera el registro a nivel aplicación. También regresa la forma al estado ``View''.

5) En cualquiera de los procesos (insert, update, save) se puede verificar el estado de locks que estén obsoletos (ya que se prevee que todo lock tenga expiración) y/o se anadirá un proceso tipo crontask que verifique el estado de los locks obsoletos.

6) Se prevee que los objetos sean consientes del usuario y su permisología. Los privilegos actualmente serás: View, Insert, Delete, y Modify. [2]

Anatomía de una Foma y su Relación con el RDBMS:
================================================

Se preveen los siguiente niveles de widgets:
     1) Nivel Aplicación
     2) Nivel Tab
     3) Nivel Forma
        3.1) Nivel Campo, Label, Checkbox (cualquier widget HTML4)
        3.2) Nivel Detalle (es una tabla de datos)
               3.2.1) Fila
               3.2.2) Columna
        3.3) Nivel Sub-Detalle
              .
              .
              .
        3.x) Nivel Sub-Detalle

Reglas y Relaciones:

(ojo que todavía no he oficializado los acrónimos y pueden cambiar en un futuro)

1) Una forma contiene un tab principal llamado "Main Application Tab" o Master Record (MR). Un MR está asociado a una tabla de la BD (aunque puede tener foreign keys) y por ende a un query.
2) Un MR puede tener información principal y también una sección de detalle (DR - Detail Records). La sección de detalle está asociada a una tabla de la BD y aun query que incluye en su WHERE la condición del MR o registro principal. La relación entre el MR y el DR por supuesto es un a muchos.
3) Un DR puede tener más DR pasando en cascada la condición WHERE.
4) Un MR puede tener registros secundarios (SR) que correponden a los "Secondary Tab" en el UI.Igualmente los SR pueden tener DR en cascada como un MR y heredan la condición WHERE del MR.

Bueno, esto termina la conceptualización de las formas de más bajo nivel y la funcionalidad que quiero prestar en el alpha inicial y probablemente no preste mucho más en la primera versión. Aunque para la primera versión quiero añadir etado de documentos, trazabilidad de cambios (CFR Part 11), perfil de usuario, las inerfaces para un workflow genérico, etc.. Estas cosas la anadiré después de mostrarles código actual con la funcionalidad descrita arriba.

Soy todo oídos. SHOOT!

Saludos a todos,
Alejandro Imass

[1] En mis modelos UML los estados son realmente clases frontera que representan a una forma en un estado en particular. Los procesos con clases de tipo proceso que ejecutan una acción. Cuando hable de registro o entidad me refiero a la clase entidad. Todos los elementos mencionados con de los diagramas de colaboración de clases que estoy generando para el diseño y que voy a publicar en una página web posteriormente.

[2] Recordar que este documento solo define la funcionalidad básica de edición de registros. La permisología sobre acciones y estados del doc (aprobación, ruteo, ancelación, etc.) será definidas posteriormente.

-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze
------------------------------------------------------------------------
Enviar e-mail a <majordomo at pm.org> colocando en el cuerpo:
"UNSUBSCRIBE caracas-pm-list" para desuscribirse.
"INFO caracas-pm-list" para conocer las reglas de etiqueta.
------------------------------------------------------------------------