(Paréntesis) Compartiendo ideas y experiencias...

Saludos de nuevo.

Ahora, voy a compartir una experiencia que tuve en mi trabajo de la cual, como todas las experiencias, fue muy enriquecedora. En mi trabajo no tengo la oportunidad de trabajar mucho en Java, debido a que allí utilizamos php como lenguaje para resolver un Sistema Administrativo para que se adapte a las necesidades de nuestro Instituto INZIT. Por lo tanto en mis ratos libres aprendo un poco más sobre Java, ya que me considero amante a este tecnología.

Hace poco teníamos una duda acerca de cómo debíamos imprimir un reporte, de hecho era como imprimir el cheque, por experiencia pasada sabíamos que un PDF no era buena idea ya que la impresora de matriz de punto que se utiliza para este fin no generaba buenas impresiones PDF en ninguna fuente y también por experiencias pasadas sabíamos que la solución para este tipo de impresora era un archivo HTML en pantalla o texto plano (txt).

Pero había una restricción más para nuestro requerimiento de sistema y era que el cheque debe imprimirse una vez, y por lo tanto debe asegurarse que el cheque sea impreso en la forma adecuada.

La primera investigación que hicimos fue que JavaScript tiene la funcion window.print() que imprime el contenido en la ventana y también document.print() que puedo adaptarlo a que me imprima una sección de la página (como un DIV de HTML, por ejemplo). Ahora bien, las restricciones que vimos es que no había manera de determinar si el usuario presionaba click en "Imprimir" o "Cancelar" y por lo tanto no garantizaba que se realizara la impresión y de ser así para el sistema puede que ya se había impreso o cambiado el estado del cheque (y de otras tablas relacionadas más) por más que el usuario haga click en cancelar.

Al no gustarnos esta solución fuimos buscando otras alternativas, de allí surgió la idea, ¿Podríamos utilizar un applet de Java? Bueno, la idea era buena, que tal si por java podríamos capturar si se manda a imprimir satisfactoriamente o no y de allí cambiar los todas las tablas y los estados de nuestra base de datos para garantizar de que en verdad se mandó a imprimir y por la impresora correcta.

Bueno, la duda surgió un viernes y se esperó el fin de semana. Al otro lunes ya teníamos la solución en verdad el Applet lo puede hacer, de hecho, puedo capturar un archivo HTML, cargarlo en un JEditorPane mostrar el cuadro de diálogo imprimir y verificar si el presionó sobre Imprimir o Cancelar.

Total empezamos a desarrollarlo y a cuadrarlo con las dimensiones de los distintos formatos de cheques que tiene la nuestra empresa. Y en tres días pudimos hacer que nuestra aplicación PHP generara un archivo HTML en disco duro servidor, conectar en Applet con este archivo a través de un URL, mostrarlo en el JEditorPane y mandarlo a imprimir cuadrando con las dimesiones de todos los cheques. Eureka estaba listo!.

Bueno, pero no todo fue color de rosa.

Si por una parte podíamos hacer que se visualizara el HTML en el JEditorPane, este editor de Java no soportaba las sentencias más recientes de CSS como posicionado absoluto, muy importante para darle una ubicación exacta y no relativa, por lo tanto, cuadrarlo dio mucho trabajo.

Pero después de tenerlo hecho se nos presentó una idea nueva, nuestro jefe por experiencia en desarrollo de Sistemas Administrativos dijo que si era posible imprimir más de una vez el cheque si éste a pesar que se mandó a imprimir en forma satisfactoria, en realidad se mandó a imprimir en otra impresora que no era la de matriz de punto, esto trajo una variable nueva a nuestro sistema, ya no era necesario detectar si se daba click en Imprimir en cancelar, después de todo los datos del cheque ya estaban generado y se podía imprimir de nuevo si así el usuario lo necesitaba, así lo que que hicimos fue que siempre se iba a imprimir el cheque por PHP y JavaScript, pero sólo se imprimía de nuevo el cheque con una autorización del Jefe del Departamento Administrativo.

Bueno total, me quedé con el código Java, con la clase Applet que permite capturar un archivo HTML, presentarlo en pantalla a través de un JEditorPane y poder imprimir, inclusive configurando desde códigos las configuración de impresión como márgenes y otros.

En el próximo post explicaré con detalle el código que pude desarrollar a ver si a cualquiera de ustedes les sirve. Por ahora, lo más importante que quiero compartir es que cuando se tenga una idea de software de cómo desarrollar cierta aplicación hay que ver y discutir todas las opciones, es decir, después de recaudar los requerimientos de sistema, ver qué se debe desarrollar: ver las ventajas, desventajas de cada opción y sobretodo no programar "linealmente" cómo fue solicitado, ya que de seguro vendrán cambios en la aplicación mas adelante, el reto, para nosotros los desarrolladores es detectar los elementos claves del sistema y desarrollar en base a esto y después que el usuario quiera un cambio, este no debe afectar al desarrollo normal del sistema, lo que significa que si la lógica del negocio no cambia, el cambio debe ser adaptable en poco tiempo, ya que los elementos raíces se mantienen.

No intento relatar una idea nueva, esta idea ya ha sido expuesta en varias metodologías de desarrollo de software, sólo intento compartir una experiencia que me sucedió y que todavía estoy procesando, creo que la programación va más allá de resolverle a un usuario, la programación es detectar la lógica del negocio, para que éste mismo sistema pueda funcionar en distintos ambientes, empresas, negocios y usuarios, por ello nuestra labor será trascendente cuando nuestro trabajo lo sea y pueda resolver y adecuarse a las distintas pruebas.

Espero que esta idea les sea de utilidad y empecemos a detectar que necesita el hombre de nuestros días y a partir de ellas crear ideas... ¡Hasta la próxima!

Para ver la segunda parte de este artículo haga click aquí:
Paréntesis. II Parte. Compartiendo Código Applet