Desarrollo web Boostrap dwr

Durante mi vida como programador de aplicaciones , he pasado un largo camino, desde mi primeras aplicaciones en CPM86, luego DOS, Windows en todos sus sabores, Solaris , Unix, Xenis,  y por ultimo en Linux , siempre la dificultad contante independiente del lenguaje Basic, Pascal, Cobol, RPG, 

Foxpro, ,C, C++, Java es el ambiente o capa de usuario , en un principio esa dificultad se desdibujaba pues no existia primero una gran expectativa respecto a ese tema y de alguna manera uno se las apañaba para que la captura fuera medianamente practica y hasta de pronto bonita, sin embargo esto no era ni de lejos un requerimiento era mas bien un gusto estético nada mas, lo importante era que funcionara bien no que fuera bonito.

Paulatinamente Windows fue imponiendo sus sistema gráfico y se vieron nuevas posibilidades y hubo un momento donde lo estético primo sobre lo practico, pero aun así, los desarrolladores seguíamos enfrentados mas a los problemas derivados del manejo de bases de datos y de los controladores del sistema es decir las reglas del negocio  o de la aplicación según el caso  , que en la parte estética e interfaces de usuario, paulatinamente fueron apareciendo kits, o programas d desarrollo que empezaron a enfatizar mucho en el tema de las interfaces de usuario.

Java entre otro propuso sus modelos gráficos tipo AWT, Foxplus pasa ambiente gráfico,  GTK, Qt entre otros para C y C++ etc.

Con el advenimiento de Internet, la situación que se venia presentando respecto a la captura de información y su presentación estética se enfatizo, ni siquiera pienso que fuera a propósito sino que de forma natural html, hacia un manejo propio gráfico sin muchas campanillas mas que aceptable.

Simple, elegante, fácil de entender incluso para legos en la materia, cualquiera con un conocimiento sencillo podía hacer una interfaces gráfica mas que aceptable, aun no estaban de moda los diseñadores gráficos , ni los front-end, todo se hacia a pelo.

Pero pronto fue evidente y  se puso de manifiesto que al ser html un modelo de captura de información sin estado (no guarda los datos) , la simple captura de información no bastaba y era prácticamente inútil para el desarrollo de aplicaciones mas pesadas, salvo alguna presentación de escritorio o informes de gerencia.

Dado el estado de cosas, se vio que era indispensable la creación de una propuesta que permitiera no solo capturar la información , ahora ya bonita sino también poder almacenarla y desde luego poder usarla.

Quedo aquí planteado  el problema de fondo, y es que a todas luces se vio que había una separación entre el manejo de la información que posteriormente se denomino backoffice y la presentación y captura de la misma back-end.

Surgieron innumerables propuestas para paliar el problema siendo el mas connotado el modelo CGI,  donde forma practica aunque no fácil, se programa todo la captura de información en un servidor html (apache entre otros) y el manejo de la información por otro en un lenguaje, eventualmente en C, C++.

La verdad la solución era practica como digo, pero no era precisamente para legos, la cosas se las traía, porque quedo claro que la persona que pretende dar pasos en este proceso debía conocer y no de cualquier manera , redes de comunicación, html, contendedor o servidor de aplicaciones tipo Apache, integración de aplicaciones, un lenguaje tipo C, C++., un ingeniero integral todo en uno.

Inmenso desafió porque conseguir profesionales con este perfil no solo era difícil sino muy costoso y altamente peligroso porque todo el conocimiento estaba centrado en poquísimas personas de una organización , lo que los volvía virtualmente indispensables e inamovibles.

Empesaron a surgir propuestas de forma tal que se presentara una clara sepacion entre lo que se denomino el IDE (interfaces de usuario) y el Modelo.

En virtud de esta propuesta teórica la persona que se encargaba del IDE, poco o ninguna formación en programación debería tener, solo se preocupaba por la estética del programa , y el modelo era soportado por 2 tipo de ingenieros que en teoría tampoco tenían nada que ver entre si y no se pisaban los cables como se dice, uno en el diseño , soporte y mantenimiento de los dispositivos  modelos de almacenamiento (bases de datos) y otro ingeniero que se llamo arquitecto se encargaba en si del modelo de operación de la aplicación y era quien conocía las reglas del negocio, formulado o no en ese momento esta separación funcional y operativa muto a lo que en su momento se llamo MVC (modelo-vista-controlador).

Y claro vinieron los temas de servidores, comunicaciones, seguridad y demás, pero no nos vamos a centrar en eso.

En teoría insisto era simple, claro, preciso incluso elegante, como quien dice zapatero a tus zapatos y cada quien a su labor.

El problema fue que una cosa es plantear una solución y otra bien distinta implementarla con un agravante para nada despreciable, y que se hacer con las inmensas inversiones en los sistemas que había, que para nada hacían eco de esta propuesta.

Aparecieron innumerables propuestas para tener en cuenta lo nuevo con lo había, algunas buenas otras regulares , pero sin duda todas son falta requerían una curva de aprendizaje mas que mediano y en el fondo no solucionaban de forma definitiva los problemas de fondo de compatibilidad con lo que se tenia , pero peor aun no solucionaban el tema de separación de funciones del MVC, (Nota : en este documento MVC, se refiere mas a separación de funciones de los desarrolladores de crear interfaces, manejar datos y crear modelos  desde punto de vista logístico, que el paradigma de arquitectura de este mismo nombre) aunque muchos se ufanaban de hacerlo la verdad es que poco o nada aportaban al problema de fondo.

En mi caso empece a explorar con diferentes contenedores de aplicaciones (Apache , Tomcat, NetBeans) , lenguajes, PERL, PHP, Ruby, Javascript y mezclas y variantes de los mismos, diferentes bases de datos MySQL (MariaDB) , Postgres, Cassandra,  Mongo, IDE como Eclipse, propuestas con FACES, y Prime Faces, gestror de contenido OPENCMS  etc y diferentes modelos de acceso al servidor tipo AJAX, tengo que confesar que hace ya mucho tiempo me aparte de los sistemas propietarios  y me centre en propuestas del software libre, sin embargo todo esto me dejo siempre con un sin sabor de que las mezclas  en la parte de desarrollo de IDE estaban bien presentes y se requería un conocimiento de lenguajes de programación por parte del diseñador lo que seguía amarrando esta etapa del proceso, pues lo mas que se conseguía era tener un buen diseñador que hacia cosas tipo mona lisa en su pantalla pero a la hora de implementarlas queda en manos de un programador ponerlas a funcionar, lo mismo de siempre pero un poco ,  menos engorroso.

Al fin después de tanto buscar me quede con dos algunas herramientas que me funcionan, oiga-se bien me funcionan sin llegar a lo que quiero pero que de alguna manera me dejan un margen de libertad al desarrollar y contratar personal estas herramientas a saber son:

Servidor de aplicaciones TOMCAT

Modelo de desarrollo JSP

Lenguaje en el Front-end JAVASCRIPT

Lenguaje en backoffice (Modelo controlador) JAVA

Modelo de acceso backoffice DAO

Base de datos (Postgresql para SQL , MongoDB para NOSQL)

Modelo de acceso al servidor DWR  , (equivalente Ajax para Tomcat)

Interfaces de usuario HTML - CSS - BOOSTRAP4

Se que parece mucho pero en realidad no hay tal,

El uso del contendedor Tomcart y JSP, se usan para la mínimo solo para cargar

la aplicación y una que otra instrucción suelta JSP, mas que todo de carga y fragmentación de código con INCLUDE para no hacer las el código muy largo y difícil de comprender, pero claro es cuestión de gustos no de funcionalidad, aquí el conocimiento JSP es incidental y mínimo así como de Tomcat.

El Java se usa para el modelo DAO y son instrucción simples y sencillas llamadas a procesos bean, que en la mayoría de los casos son conexiones mediante interfaces a las bases de datos, no se necesitan conocimientos esotéricos de java mas allá de instrucciones como String, Vector List. y el manejo sencillo de clases y claro los bean.

El modelo DAO que como sabrán esta divido en DTO donde se definen todos los bean que en general en mi modelo son solo las definiciones de variables que son disponibles al sistema y procedimientos que puede ser llamados por el diseñador con un mediano conocimiento Javascript tan simple como la función:

                                     Var Array clientes = LlamarCliente{}

Previamente definida en el DAO  y de la cual el diseñador gráfico nada que ver.

Donde están las clases de presentación de la información de las bases de datos , calculosos y demás de interés.

Que en general consiste en leer la base de datos y llenar un vector o list con la información pertinente  de los bean definidos en DTO , para que el diseñador tenga acceso a todas y cada una de las variables del sistema sin restricciones.

EL Boostrap 4 lo elegí porque en el mercado muchos diseñadores los usan , lo conocen y se sienten cómodos con el,  yo no tengo un manejo exhaustivo del mismo pero me a parecido sencillo y fácil de mantener.

He explorado algunos Framework pero la verdad no es que me aporten demasiado comparado con CSS3 y Boostrap, decidí quedarme con este.

En cuanto a Javascrip , bueno Javascript es javascript el esperanto de los lenguajes de programación.

Y el DWR es ajax , en este caso uno muy robusto y simple de implementar , tan simple que solo basta copiar la librería DWR en el Tomcat y una definición del, lugar y nombre(s) de los procesos a exponer del DAO , poco mas o menos, luego no hay que tocarlo para nada y a partir de alli  las variables definidas en el DTO del backoffice quedan disponibles en el front-end

Esto así planteado y dada la sencillas de lo que tengo planteado, desarrolle algunos scripts de auto generación de aplicaciones por ejemplo CrearClientes.sh

donde solamente le doy el nombre de la tabla donde definí toda la información del cliente,  el sistema me genera el DTO , DAO y el IDE de acceso a clientes en 

formato CRUD.jsp, (Crear-Leer-Actualizar,Borrar), me queda una aplicación mas o menos al 90%,  para afinar algunas variables que no están en las tablas como son algunos cálculos  y ajustar algunos mensajes , poco mas o menos y las interfaces de acceso al sistema las contrato con algún diseñador de turno y lo dejo que se de gusto descrestando con luces y colores, total es totalmente boostrap4  y no hay que meterle mano para nada.