Expedientes. Actuaciones.

Registro de actuaciones

En una versión anterior de esta entrada empezaba diciendo que me proponía desarrollar una primera "aplicación" en Python, similar a lo que podría hacerse con OOo Basic, a modo de docap simple, con el objetivo de comparar la funcionalidad de ambos lenguajes. Este sigue siendo el objetivo de la propuesta que aquí presento, pero su propio desarrollo me llevó a profundizar en el significado de que lo que es un soporte para el registro de las actuaciones. Esta implicación es doble, aunque por ahora priorice uno de los enfoques:

• Por un lado está la creación de un recurso (o DocAp) para facilitar el registro informatizado de las actuaciones de los profesionales de los SEO, un ejemplo como otros del propósito de favorecer la automatización de los soportes documentales empleados por los SEO mediante su informatización.
• Por otro lado está realizar una revisión de la práctica profesional de los SEO, acompañada de la (re)formulación de los recursos y de los medios de intervención.

En ambos casos justo es reconocer que únicamente estamos dando los primeros pasos.

Quiero decir también, por lo que a la propuesta documental se refiere, que posiblemente y desde un planteamiento más reflexivo que el meramente "técnico", sería necesario plantearse la propia pertinencia de concretar esta propuesta como DocAp o aplicación, pudiendo considerarse con motivos que una mera formulación como documento-soporte podría ser suficiente para cumplir el objetivo que aquí parecer plantearse. Tal vez un documento-base acompañado de una macro, sin llegar a formular un DocAp pordría ser suficiente. Como ejemplo de esta propuesta podría servir este documento.

No quedarse en una formulación de esta naturaleza es la consecuencia de nuestro interés por desarrollar las posibilidades que permite el uso básico de Python y comparar los resultados con lo que obtenemos con DocAp basados en OOoBasic. Pero faltaría a la verdad si no planteara que también han influido en esta propuesta lo que deriva del análisis del significado y la funcionalidad que tiene la formulación de un sistema de seguimiento de las actuaciones.

Los documentos y materiales que dejo al final de esta entrada recogen dos propuestas que tienen un mismo objetivo, aunque expresado en dos lenguajes y mediante dos procedimientos diferentes: un DocAp creado mediante OOo Basic (macros y script) sobre LibreOffice frente a una "aplicación" construida como script de Python que crea un archivo al que podemos acceder desde LibreOffice en forma de Writer, por lo que es susceptible de ser tratado mediante macros.

Explico a continuación las dos propuestas, como dije, dos recursos pensados para recoger las actuaciones realizadas por el SEO:

• El primero crea el documento, esto es, su encabezamiento y los datos de identificación.
• Y el segundo sirve para recoger las actuaciones propiamente dichas.

No son recursos plenamente desarrollados, tan sólo soportes básicos, especialmente el creado mediante Python, mejorables tanto en funcionamiento como en su código; mejoras que se irán implementando en versiones sucesivas. Esa es la idea.

Podemos diferenciar dos enfoques en la comparación entre ambos, el de los componentes y el de los procesos. En el de componentes, diferenciamos...

• El de los DocAp, creados en OOo Basic, que se desarrollan desde dentro del documento-soporte y se descompone en el IDE en dos módulos ubicados en documento; cada uno de ellos pensado para responder a las dos actuaciones antes indicadas.
• Y el de los script de Python, que se implementan desde el cmd (o Símbolo de sistema en Windows), que se concretan en dos script externos al documento txt-odt, siendo éste generado por el primero de los script y al que se accede desde el segundo. De forma complementaria se puede crear un documento pdf mediante un script OOo Basic como forma de "congelar" el resultado en un momento dado.

En cuanto al proceso, OOo Basic presenta una estructura modular en la que se combinan tres script: el usado para acceder a las funcionalidades básicas de Grabar macro, el nuclear del componente y una subrutina auxiliar de escritura.

Python presenta en este momento una estructura secuencial lineal simple, donde se distinguen tres fases: la de input, el acceso/creación del documento y la escritura en el mismo, y el cierre del documento. Finaliza con un procedimiento controlado de cierre del script.

No me voy a detener aquí en explicar el código OOo Basic, aunque recomiendo acceder a él desde el IDE del documento-base que se puede descargar desde el enlace ubicado al final de la entrada. Sí analizaré brevemente el código Python, recomendando también profundizar en el estudioél de estos dos script. Ahora me centraré en el script ActuaNueva.py

• Fase 1. Entrada de datos (input): Como en Python no hace falta declarar previamente las variables, lo hacemos implícitamente en el mismo momento en que se solicita el dato mediante la función: actua_fecha=input("Fecha de la actuación (dd/mm/aaaa): ")
• Fase 2. Escritura en el documento, si bien previamente (fase 1) accedo al soporte, primero de forma interactiva... (seo_archivo=input("Código de indentificación: ") y después mediante la sentencia with open(seo_archivo + "_Actua.odt","a") as file: y el uso de la función write() que permite la escritura del contenido en el documento abierto (file.write("ACTUACIÓN " + actua_fecha))
• Fase 3. Cierre del archivo y del cmd. El primero (file.close()) cierra el documento abierto en la fase anterior, siendo este el modo de asegurar la actualización de su contenido. El segundo permite controlar el cierre del script y del cmd. Para ello se usa la función input() sin ningún contenido.

Quisiera incidir ahora en dos cuestiones que considero de interés. La primera es el uso de la función print() para informar al usuario del modo de proceder y del propio proceso, dar cierto formato al texto y también a la forma en que se presenta la aplicación en el cmd, incluyendo la presentación de opciones (ver script): print("Datos de la actuación.---"). La segunda tiene más importancia ya que se refiere al manejo del archivo de texto, puesto que en cada script es diferente. En este se accede a un documento ya existente, por lo que primero se solicita el identificador del documento (mediante input()) y después se utiliza la expresión open(seo_archivo + "_Actua.odt","a") mientras que en el otro script (ExpedNuevo.py) se trabaja con un documento no creado, por lo que empleamos open(seo_archivo+"_Actua.odt","w")

La diferencia, aunque mínima (a vs w) es fundamental, dadas las funciones atribuidas respectivamente a a (acceder a un documento existente y posicionarse al final del mismo con permisos de escritura) y a w (acceder a un archivo borrando su contenido. Si el archivo no existe se crea) que son las que marcan el comportamiento específico de cada uno de los script.

Para finalizar, llamar la atención del lector respecto a la peculiaridad que presentan estos script en cuanto al input: basarlo en el cmd es una forma de aparcar el tema de la GUI para centrarse en cuestiones de codificación (lenguaje y expresión algorítmica). Pero este modo de trabajo no es sólo resultado de lo que no se aborda, también es un modo de trabajo cuando los lenguajes de programación se emplean como recursos profesionales y no para crear productos para "el mercado". Cuando nos centramos en crear nuestras soluciones para nuestros problemas las formas pasan a un segundo plano en favor de la funcionalidad. Por eso no es extraño encontrar quienes prefieren trabajar directamente en línea de comando sin usar interfaces gráficas (GUI). Este es aquí también mi enfoque.

Materiales:

• Docap basado en LO-Writer (plantilla). Ver macros desde el IDE
• Script Python: ExpedNuevo.py y ActuaNueva.py
• Ejemplo de documento ACTUACIONES y formato .pdf
• Macros para tratamiento del documento y conversión en .pdf