Pensando en el browse...

Esta semana estaba un poco a la espectativa de como se movía la gente con la presentación de form-io por parte de Quim. Como comenté, creo que el concepto es bueno en el ámbito de como crear pantallas.

Pero la verdad pocos han probado el sistema, supongo que aun queda madurar un poco el tema del diseñador.

También he visto a un par de programadores haciéndose un poco de lio todavía de como funciona el sistema. Creo que es muy fácil de entender y abstrae muchos conceptos que son necesarios aprender para programar web.

Entonces llegamos también al momento en que si no puedo ir por el camino diseñado, pues voy por otro y allá empieza mas lio. También el que pone su pluggin y no sabe como conectar.

Ya comente que miraré este proyecto solo por la línea diseñada, no voy a estar mirando porque un pluggin falla o no. Quien tenga un problema en el concepto lo iré arreglando, pero el objetivo y el camino es este. Si alguien quiere ir mas por el standard de la programación web, le recomiendo el v2.1

Ahora toca acabar de perfeccionar este modelo de trabajo. 

Me doy cuenta que el problema casi siempre son los browsers. Los grids es el control mas complejo a programar porque necesitas mas técnica que los otros y sobretodo...cada uno tiene su visión de como debe de trabajar.

Hasta ahora tenemos un modelo httpd2 que funciona bien con los controles estandards y que mas se usan, pero toca pensar ahora un poco con el tema grid. Cree un wrapper para usar usar un pluggin q me parece muy bueno, para poder facilitar este trabajo. Quien se salga de este pluggin tendrá que crear una tabla manualmente o usar otro pluggin, no hay mas, pero el problema está en como crear algo que sirva para programar dinámicamente este pluggin para gestionar el browse.

El tema esta en como  encajarlo en el concepto. Partimos de la base que una ventana tendrá su api que apuntará a nuestro servidor y que recibirá las diferentes peticiones de nuestros controles. Esta api las recibirá, procesará y contestarå. No hay mas, pero y el grid ? Como lo podemos tratar?

El sistema esta diseñado para q cada vez que queramos algo del servidor, se enviará todo el contenido de todos los controles que tengan el tag data-live al servidor para que pueda procesar lo que necesite y contestar. Por esto la importancia hasta aquí del tag data-live, si tenemos 30 controles en la pantalla, peros solo 10 usan datos relevantes, pues serán estos los que se envíen al servidor.

Pero... y los datos de un grid? 

Analizando un poco casuïsticas que nos podemos encontrar, todo depende de la situación y el escenario en que nos encontremos. Imaginemos que hemos cargado en una tabla 10 registros. Siguiendo con nuestra lógica del sistema, si tenemos un campo input que le metemos un tag data-onchange, al modificar el contenido se enviaran todos los controles al server, pero que hacemos con esta tabla?

- Enviamos los 10 registros ? Y si son 100000 ?

- Enviamos solo los actualizados?

- Y si borramos algún registro de la tabla ?

- Y si enviamos solo lo actualizado/eliminado?

-...

Pero...

Y si el server recibe algún input de un control get, que necesitas actualizar, eliminar linea, vaciar, ...?

Es por eso que necesitamos algo standard q se adapte bien y que sea muy dinámico. 

Porque el problema aparece luego en..., como pongo en la linea esto? O como meto un botón q haga tal? 

A priori detecto los siguientes métodos a ejecutar en browse desde el servidor:

- Crear un browse con su estructura y si es necesario datos

- Eliminar contenido

- Actualizar un registro

- Añadir un registro

- Recuperar los registros en función de la definición

Aqui por ejemplo, entiendo que un browse y en función del proceso que estamos diseñando, será necesario enviar:

- Todos los registros

- Solo los modificados y eliminados

- Todos + modificados + eliminados

También debemos intentar controlar algún evento básico como dlbclick, change,... y esto debe disparar alguna función javascript (básica) para realizar alguna acción.

Hay un montón de cosillas a tocar en el browse, por eso todo depende de lo que estemos programando.

Todo estos escenarios son muy fáciles de resolver usando cada lenguaje en su sitio, el problema es como encajamos todo el tema para ir por nuestro camino.... Y nunca debemos desviarnos del objetivo que es intentar crear una herramienta para que fácilmente y sobre todo rápidamente podamos crear pantallas web completamente funcionales.

Lo conseguiremos para que sea fácil de usar para todos