Modelo básico de DocAp (a)
Siguiendo lo expuesto en [esta entrada] me propongo en la actual presentar un docap-modelo sobre el que basar la semi-automatización de la creación de documentos en LibreOffice. Dado que se trata de un modelo básico, no contempla lo que de específico podría tener su aplicación a un problema concreto. Será en el abordaje de tareas específicas donde este modelo se desarrolle adaptándose a las necesidades que se presenten en cada caso.
Un docap básico de manejo de documentos emplea los siguientes servicios: un soporte de gestión, basado en Calc y un documento-output en blanco generado en Writer. Esta es la primera y básica formulación del docap-modelo.
El primer documento o Gestor contiene un formulario, cuyos controles se asocian a celdas, que sirve de interface visual y facilita la entrada de datos. En este documento se desarrolla el procesamiento de los datos mediante código OOo Basic. En este código se diferencian tres subprocesos:
- El que permite el acceso a los datos (input)
- Su tratamiento, del que resulta el contenido textual
- La creación del documento-writer y la escritura de contenido general en este documento.
Tras este proceso, el documento resultante podrá ser modificado según decisión del usuario y posteriormente archivado donde se considere adecuado. Es por esto que hablamos de semi-automatización del procedimiento y no de automatización en sentido estricto: el documento resultante queda disponible para el trabajo del profesional.
Explico a continuación los pasos necesarios para desarrollar este docap, empezando por la creación del documento Calc (Gestor) al que daremos el nombre que mejor represente la función del docap, documento en el que implementaremos un módulo para los script OOo Basic.
Dado que el input se basa en un formulario, los crearemos en Hoja1 según el procedimiento también conocido, asociando los controles a determinada columna de celdas (en este modelo, a la columna I); con él resolvemos la entrada de datos (input) del docap (1).
La segunda fase consiste en acceder a los dato introducidos por el usuario mediante el formulario; para ello crearemos el script desde el IDE de Calc.
En el script principal Main (2) crearemos cuatro variables y dos matrices; dos variables de tipo Object para el acceso a la hoja y a las celdas (oHojaActiva y oCelda), una matriz para contener los datos (mDatos()) y otra para identificar las celdas que los contienen; finalmente dos variables tipo Integer (n y i) respectivamente para dimensionar la matriz y como contador del bucle For.
Dim oHojaActiva As Object, oCelda As ObjectDim mDatos() As String, mCeldas() As StringDim n As Integer, i As Integer
El paso siguiente consiste en acceder al contenido de las celdas. Para ello elaboramos las siguientes instrucciones (3):
oHoja = ThisComponent.getSheets().getByName("Hoja1")n = 4ReDim mDatos(n)mCeldas= Array("I1","I2","I3","I4","I5")For i = 0 To UBound(mDatos())oCelda = oHoja.getCellRangeByName(mCeldas(i))mDatos(i) = oCelda.getString()Next
- La primera nos facilita el acceso a Hoja1 del documento Calc (oHoja = ThisComponent.getSheets().getByName("Hoja1")), lo que nos permite el posterior acceso a las celdas.
- Mediante la variable n ajustamos el tamaño de la matriz mDatos() al número de componentes resultante del formulario (en este caso 5, de ahí n=4) en función de la instrucción ReDim (ReDim mDatos(n))
- Aunque no es la única opción posible, establecer directamente el contenido de la matriz mCeldas() (mCeldas= Array("I1","I2","I3","I4","I5")) (4) nos permite trabajar después con más comodidad con el buche For
- Finalmente, mediante este bucle recorremos el conjunto de celdas (For i = 0 To UBound(mDatos())), capturando su contenido (oCelda = oHoja.getCellRangeByName(mCeldas(i))), el cual asignamos a los elementos de la matriz mDatos() (mDatos(i) = oCelda.getString())
Esto nos va a permitir trabajar con dicho contenido (fase de procesamiento) mediante código, pero es precisamente en esta fase en la que más complicado resulta definir el contenido de un docap de este tipo, dada la diversidad y la complejidad que derivan tanto de los posibles objetivos como de la cantidad de datos.
En cuanto a diversidad de objetivos nos vamos a encontrar con tareas que únicamente requieran concatenar datos (cadenas y variables), junto con otras que requieran desarrollar complejos sistemas de bifurcación en base a estructuras condicionales (árboles de decisión).
Y si nos atenemos a las implicaciones del aspecto cuantitativo, la complejidad de lo anterior se ve incrementada en la medida en que lo hace los datos, añadiendo como tercer factor, derivado de la combinación de ambos, el manejo de los datos resultantes del propio procesamiento (5)
Esta diversidad opciones y complejidad de estructuras aconseja que la fase nuclear de procesamiento reciba un tratamiento que podríamos llamar "de caja negra" en lo que a la formulación de un docap-base se refiere. De este modo, no se aborda en el modelo de docap, manteniendo éste la coherencia y simplicidad del proceso que interesa especificar, y el abordaje de dicha fase caja negra se puede trabajar de forma independiente y específica. Esta es nuestra opción, más por necesidad que por virtud.
Entendiendo aplazado el tratamiento de la fase de procesamiento, quedará resumida y representada por una variable de síntesis (6) que denominaremos sTexto y que contendrá el resultado teórico del procesamiento que eludimos en estos momentos. sTexto es, en todo caso, una variable conformada mediante procedimientos de concatenación, y eso es lo que representamos mediante su expresión formalizada en nuestro script (7):
sTexto = "Dado que Dato1 es " & mDatos(0) & " y Dato2 es " & mDatos(1) & " entonces el resutado es " & sRespuesta1 & Chr(13) &_
"Además, Datos3 es " & mDatos(2) & " y Dato4 y Datos5 son " & mDatos(3) & " y " & mDatos(4) & " respectivamente."
Sobre esta variable construiré la siguiente fase del docap-modelo, en la que se crea el documento y se escribe el texto. Esta fase se externaliza como subrutina que es llamada desde Main (Info(sTexto)), la cual paso a explicar a continuación:
Sub Info(Txt As String)
Dim sRuta As StringDim mArg()Dim oDoc As Object, oDocum As ObjectsRuta = "private:factory/swriter"oDoc = StarDesktop.loadComponentFromURL(sRuta, "_default", 0, mArg() )oDocum= oDoc.TextoDocum.insertString(oDocum.getEnd(),Txt, False)End Sub
Mediante la variable sRuta aplicamos la instrucción que nos da acceso al servicio Writer (sRuta = "private:factory/swriter"); esta instrucción es utilizada desde la asignada a oDoc (oDoc = StarDesktop.loadComponentFromURL(sRuta, "_default", 0, mArg())), que crea el documento Writer en sentido estricto y lo muestra en pantalla, con lo que nos posiciona en él.
A la variable oDocum asignamos el acceso a la propiedad .Text del documento creado (oDocum= oDoc.Text) y sobre ella desarrollamos la instrucción que emplea el método o función insertString() (oDocum.insertString(oDocum.getEnd(),Txt, False)) que es el que nos permite escribir en el documento, y al final del mismo (oDocum.getEnd()) el contenido de nuestra variable-resumen (parámetro Txt -> sTexto).
El resultado que obtenemos es un documento Writer que contiene la información que deriva del conjunto de procesos anteriores. Este resultado constituye el output del algoritmo y proporciona una forma de concretar el almacenamiento de la información resultante (8).
Documento. Puedes acceder [al docap-base desde aquí]
NOTAS
(1) Al tratarse de un docap-base eludo complicaciones ahora innecesarias, como usar distinto tipo de controles de formulario y me limito a crear un soporte-input básico. Lo que perdemos de estética y funcionalidad lo ganamos en simplicidad. Cuando crees un docap basado en éste deberás adaptar el formulario a las necesidades que presente tu proyecto, incluyendo la parte estética. Es importante la presencia de los comandos CREAR DOCUMENTO y BORRAR, ya que evidencia el modo en que se espera que el usuario interaccione con el docap: a través del formulario y de los comandos que se asocian con los script. Este modo es el propio de los docap de manejo de documentos y con los de evaluación, pero no con aplicaciones similares en Python y no necesariamente con los docap de análisis de datos basados en OOo Basic. Tendremos ocasión de ver esta cuestión en su momento.
(2) Podemos darle otro nombre, pero me ha parecido adecuado mantener el que propone Calc por defecto, ya que realmente va a ser el script principal del conjunto.
(3) Podrían idearse otros procedimientos alternativos, pero este implica el uso de un bucle y de las dos matrices, lo que facilita la economía de medios.
(4) Una forma alternativa de conseguir el mismo resultado habría sido prescindir de la matriz mCeldas() y asignar directamente el nombre de la columna dentro de la instrucción asignada a la variable oCelda (oHoja.getCellRangeByName("I" & i+1))
(5) Me refiero a las variables o colecciones de datos que se generan a consecuencia de la concatenación y/o de la condicionalidad y que no forman parte del input propiamente dicho.
(6) En la práctica pueden ser múltiples variables o matrices.
(7) Se incluye una variable sRespuesta1 que queda sin explicar por ahora. Esta variable es de tipo emergente (que es lo que se pretende simular ahora) y resulta de la llamada a una función de bifurcación que se incluye en el código del docap (Function OpcionD1 (op As Boolean, D2 As String) As String) pero que no se explica en estos momentos en base a la decisión asumida de eludir la fase de procesamiento.
(8) No explico en esta entrada el código asociado a cmdBorrar por ser poco relevante para comprender el funcionamiento del docap; únicamente añade, mediante código, una funcionalidad de manejo del soporte que se intuye de su propio nombre: dejarlo listo para múltiples usos sin necesidad de tener que borrar cada entrada del formulario cada vez que se utilice. No obstante, puedes consultar el script asociado a este comando el el IDE del archivo.


No hay comentarios:
Publicar un comentario
Comenta esta entrada