UT/HIX

Una de las funciones que teníamos pendientes en nuestro servidor era la capacidad de subir ficheros y ya lo tenemos 😊. La manera de subir los ficheros es un proceso un poco diferente a los demás, ya que lo forman  2 acciones: 1.- Elegir fichero/s 2.- Subir y procesar los ficheros subidos  Los ficheros que se suban al servidor van a parar a una carpeta temporal de nuestro sistema, por defecto será ./tmp. Esta carpeta es gestionada automáticamente por nuestro servidor que se encargará de mantener e ir borrando los ficheros a partir de un máximo de tamaño de la carpeta, por lo que no nos deberemos preocuparnos de nada.  Estos ficheros una vez se suben y están en la carpeta temporal, deberemos procesarlos y meterlos donde queramos: moverlos, copiarlos, insertarlos en registros blob,... A nivel de la Api que estamos diseñando para las pantallas, la codificación es similar a los otros controles.  Proceso 1 La manera html de indicar que muestre un button para seleccionar f...

Uno de los temas mas importantes en el diseño de una aplicación es la gestión de errores. Gracias a ello podemos ver por donde rompe nuestro programa. El problema empieza a surgir cuando nuestro querido harbour lo queremos portar a la web. Básicamente podemos generar un error, capturarlo y mostrar el error. El problema empieza a surgir cuando a nivel web, este viene desde una carga de pagina o desde una petición ajax. Hemos de aprender a controlar este flujo, y saber mostrar el mensaje. A esto le debemos saber sumar que nuestro httpd2 ahora es capaz de pre-procesar nuestras paginas web con nuestros {{ ... }} o insertando código prg que será procesado dentro de las etiquetas <?prg ... ?> En resumen, un escenario que debemos controlar lo mejor posible para ayudarnos al diseño de la app.  Como he comentado en muchas reuniones para mi la mejor practica es usar nuestra función _d(...) que nos sacara por el dbview la información que indiquemos y esto permite tracear muy bien la apl...

Este viernes se añadió Quim a la reunión  para mostrarnos como ha trabajado durante esta semana una nueva manera para enfocar el diseño de las pantallas https://formio.github.io/formio.js/app/builder   Durante estas últimas sesiones explique como podríamos abordar el tema de las pantallas para acabar de poner las patas a nuestro taburete. Una de las opciones era aprovechar algunos de los muchos editores wysiwyg que existen, alguno había visto por encima durante estos años pero realmente no los usaba porque creo mis pantallas de otra manera.  Fue cuando Quim me dijo: "mira Charly esto te va a gustar" y... me encantó. El Form.IO es un editor online muy avanzado que te permite crear tus pantallas arrastrando los diferentes controles y en cuestión de minutos tienes tu pantalla "pintada". Esta pantalla luego te la puedes gravar en un fichero, en una tabla, donde sea, y cuando desde tu programa la recuperas se pinta al momento.  Mi manera de pensar cuando vi eso era en cl...

Esta semana ha sido especial porque he cogido ya el viejo TWeb y he intentado portar una parte para poder mostrar la parte de las pantallas, la que mas preocupa.  En la demo inicial de UHttpd2 la parte de pantallas la codifiqué toda en html para poder entender el tema de los tags que deben tener los diferentes controles para que funcione el sistema. Al final todo funcionaba pero muchos se quedaban aún con la mosca con la parte de diseño de las pantallas, que lo veían complicado, pero ya había explicado en la anterior sesión que para llegar a esa codificación especial de tags, se podía llegar por varias vías: Frameworks estilo TWeb a modo comandos, sistema de parseo de ficheros *.rc, editor wysiwyg, traductor de pantallas windows estáticas a html,...  Es aquí porque decidí hacer un parche con TWeb (digo un parche porque no está del todo traspasada la librería) para poder mostrar todo el concepto. Tuve que tocar unas cuantas cosas y es que cuando diseñas sistemas que van mutando...

Recuerdo que montamos esta parte en el mod intentando asi emular a lo que hacia php. El sistema nos permite tener páginas mas dinámicas y podemos facilmente insertar código harbour en tiempo de ejecución <h2>Home</h2><hr> Welcome. Now is {{ time() }} .  En php seria: <h2>Home</h2><hr> Welcome. Now is <?= time() ?> . Ahora podemos ejecutar la función que tengamos en los tags {{ ... }}. Esto hace que nuestro servidor preprocese antes de enviar la página, la función que tenemos encerrada entre los tags. De la misma manera y a semejanza de php podemos crear los tags <?prg ... ?> . Esto nos permiste construcciones de este tipo: <!DOCTYPE html> <html lang="en"> <h2>Preprocesor example...<h2><hr> <?prg     local a     := time()     local cHtml := '<ul>'     local n           for n := 1 to 5    ...

Una de las entradas en el canal de skype, era del colega Javier en la que una vez probados los ejemplos, ya se los habia comido todos y queria mas. Particularmente queria avanzar en el tema de los grid. En este sistema para el grid uso el pluguin de Tabulator que considero que es muy muy bueno para el estilo de programar de los harbourianos. Pero... ya llegaremos a este estado de como trabajar o evolucionar los pluggins, ahora no toca porque necesitamos la base de trabajo. Hasta ahora hemos visto como cuando creamos el servidor, definimos una rutas que sencillamente lo que hace es que cualquier entrada en la url la traduce para dirigirla a algun  sitio, por eso lo llamamos router. Vamos a añadir un nuevo tipo de enrutamiento. Hasta ahora sabemos q podemos decir a nuestro sistema que cualquier entrada la podemos traducir a un fichero html que se encargara de enviar al navegador del cliente. Esto da una posibilidad de servir algo predefinido como una pagina web estatica, incluso en n...

He hecho un pequeño ejemplo para que se pueda ver que el sistema es independiente de cualquier frameworks. El concepto siempre es el mismo y es que el html tenga los tags que nos permitirá definir el camino a nuestra api y a nuestros procesos que se ejecutaran con los eventos del html. He hecho un pequeño ejemplo con bootstrap y el objetivo es que veais que en el código insertando nuestros tags, el sistema anda como siempre. <div class="container p-3" id="note" data-dialog data-api="api_notes" >   <div class="form-group">     <label for="name">Alias</label>     <input class="form-control" id="note-name" data-live placeholder="Enter your alias...">   </div>      <div class="form-group">     <label for="exampleFormControlTextarea1">Note</label>     <textarea class="form-control" data-live id="note-text" rows=...

El resumen lo intentaria plasmar de estar manera: - Entramos un registro para buscar datos - Pulsamos un button que automaticamente enviará una petición al servidor  - El servidor procesa la petición y devuelve los datos y le dice al navegador donde pintar el resultado - El navegador recibe la respuesta y ejecuta Este sencillo ejemplo de concepto lo podriamos plasmar en código de esta manera. (Clickando en la imagen veremos el codigo real usado para esta animación) La api se enlaza en el programa y todo listo Fácil ! 😀

Después de la demo que hice ya recibo los primeros inputs y dudas sobre todo el concepto. En skype quizás esta de Paquito me ha hecho mucha gracia pero a la vez resume muy bien el sistema. Debido a mi falta de conocimientos del mundo web, al principio no entendí en qué consistía el transpiler de de Charly. Pero después, buscando cositas empecé a caer en la cuenta, o eso creo, qué era eso que el comentaba del API, de lo de identificar el codigo html prefijandolo. Esos son los identificadores que conectan el mundo html con el mundo prg. De ahí a generar código html automáticamente hay un por así decirlo, un no demasiado enorme y grande paso. Sabemos eso y también sabemos que una app de tamaño pequeño y mediano es soportada. Faltará ponerle nombre a la criatura FastWeb, xWeb, BaseWeb, HarbourWeb, TransWeb, MinWeb, ScriptPrg, NoHtml, NoLimits, OnlyPrg Qué gran trabajo ha hecho Charly. Gracias Charly, gracias Cristóbal por mantener viva la llama Lo comente en la charla de presentación...

Bueno, finalmente pude hacer la demo de todo lo enseñado aplicado a una pequeña aplicación. Como enseñe ayer la idea partia de uno de los numerosos ejemplos que tiene FWH que es el dbfbuilder. Partiendo de la base de que en estos momentos el sistema ya traduce una pantalla a html, pues diseñé una emulando esta traducción y añadiendo los tags para controlar el LIVE del diálogo. El resultado son pantallas que pueden ser clones de las que tenemos para escritorio Nos conectamos todos los que pudimos juntarnos, creo que eramos unos 7 y el sistema aguantó como un campeón. Esto demuestra que para hacer pequeñas aplicaciones para un pequeño negocio y que se conecten unos pocos comerciales, crear pedidos, consultas,... el sistema puede ser válido.  Una de las pantallas va mostrando los usuarios que se van conectando y se puede ver claramente las diferentes ips Mas tarde pudieron probar el browse seleccionando la tabla u otra y editando en linea al modo browse de harbour. Una de las dudas qu...

Ayer por la tarde despues de mucho tiempo de no entrar en charlas de los viernes, enchufe video & micro y le di un poco al tema. Queria mostrar el concepto, el UHttpd2.  Era una sesión complicada porque era la típica que o enseñabas el resultado y como funcionaba, o todo un proceso para que se entendiera como y porque se llegaba a ese resultado. Total que iba hablando y al final solo pasaron 2.5 horas de charla jajaja. Tenia de estar pendiente de muchas cosas porque era como un puzle que debia montar y a veces no sabes donde te encuentras, donde tienes las cosas,... Al  final llegamos a la meta pero me falló la parte final en el que queria mostrar una aplicación real y se veia mal por algun tema de css que en aquellos momentos y despues de 2 horas no tenia ganas de buscar  (me dio rabia porque en el ordenador en que lo trabajo iba de fábula) . Intentaré  hoy buscar por donde se fue el tema y dejarlo listo. Es lo que pasa cuando trabajas en un ordenador y vas rápi...

Intentaré explicar lo mas simple posible como veo este nuevo sistema y que se entienda el concepto que usaremos para poder diseñar aplicaciones web. Son unos cuentos componentes a tocar y entender, pero estamos hablando de aprender toda una nueva manera de programar a la web sin usar los métodos tradicionales.  COMPONENTES Servidor Mientras que para usar el mod necesitábamos instalar Apache, no bastaba, sino que debías aprender a configurar mínimamente su entorno, firewall, permisos, … Hemos podido ver como este primer punto ya suponía un problema importante para la mayoría.  Después de probar unas cuantas soluciones Harbour la más potente bajo mi punto de vista es el servidor httpd de   Mindaugas, lo probé hace mas de 20 años, es una obra de arte y si te gusta la programación y el mundo web, puedes tener una buena lectura y aprender mucho de él. Nunca lo use en producción pero recuerdo en una charla de nuestro amigo Rafa que el comentó que lo usó con mucho éxito en una...