self.inflate bidireccional

[surtich]

Creo que sería interesante que el método self.inflate tenga un comportamiento bidireccional.

Me explico:

La principal razón de la nueva implementación del método self.inflate es automatizar tareas sencillas y evitar hacerlas en el presenter. Con efecto beneficioso colateral, en muchos casos, se evitará tener que crear el data-id de los elementos del template.

Sin embargo, creo que podemos automatizar y simplificar todavía más si permitiéramos actualizaciones semi-automáticas desde el template hacia el presenter . Pongo un par de ejemplos:

1. Supongamos que quisiéramos recuperar el valor de varias cajas de texto. Con la solución actual, tendríamos que crear los data-ids en el template y recuperarlos con sel.get(xxx).val() en el presenter. Es decir, que la ventaja que habíamos conseguido con el método self.inflate sería limitada.

2. Lo mismo podríamos decir si quisiéramos saber si un componente esta oculto o no o si tiene determinada clase, etc.

Se me ocurren dos formas de implementarlo:

a) La primera sería que el método self.inflate pudiera recibir opcionalmente una función y que iris llamara a esta función pasándola un objeto con los valores de los atributos data-jq-xxx que tenga la vista antes de actualizarse.

b) La segunda sería crear el método self.deflate que devolvería un objeto con los valores de los atributos data-jq-xxx de la vista.

Es decir, que si en el template tenemos una caja de texto:

<input data-jq-val="person.name"></div>

E introducimos, por ejemplo Pepe.

El método self.deflate, devolvería el objeto:

{
 "person": {
    "name": "Pepe"
  }
}

Me gusta mucho más la segunda opción por ser más clara de entender y de utilizar y porque desacopla operaciones (puedo hacer un inflate o un deflate a voluntad sin mezclar conceptos).

Con esto conseguiríamos, los bidirectionals-bindings de otras API MVC pero sin los problemas de rendimiento ni la introducción de lógica en la vista.

Para mi crear la función deflate no tiene mucho sentido y te explico por qué.

Dices: "Con la solución actual, tendríamos que crear los data-ids en el template y recuperarlos con sel.get(xxx).val() en el presenter."

No estoy de acuerdo con esa proposición, así es como yo lo veo:

En una página HTML la única manera que tiene un usuario de introducir datos, es usando los controles de los formularios: inputs, textareas, etc...
La mayoría de las veces, por no decir el 99.9%, se necesita validar esos datos antes de utilizarlos y además se debe indicar al usuario de manera gráfica que correcciones tiene que aplicar.
Si estas validaciones las haces sin usar algo como jquery-validate puedo entender que tengas que añadir data-ids a los controles del formulario. Yo no hago nunca, o al menos lo intento, las validaciones campo por campo a mano en el presenter, lo que hago es crearme un formulario y utilizar un plugin de jquery para montar los avisos al usuario y establecer todas las reglas de validación de una forma cómoda.
De igual manera utilizo el formulario para serializar todos los datos modificados, es decir, la función self.deflate() vendría a ser, más o menos, lo mismo que $(form).serialize().
Yo personalmente me decanto por validar y serializar la información de la manera que te acabo de explicar, por lo que no veo para nada necesario la creación de self.deflate().

El caso de saber si algo esta oculto... no acabo de entenderlo bien porque para que algo cambie a oculto se ha de hacer en el presenter si o si, es decir no hemos creado un atributo en el elemento que sea capaz de modificar su visibilidad posteriormente (después de haber sido establecida con un data-jq-*), por lo que saber si algo se ocultó o no, se sabe antes de llamar al self.inflate() desde el presenter.

Además creo que la inmensa mayoría de developers conoce jquery-validate y sabe sacar la información serializada de los formularios. Crear un nuevo mecanismo para hacer de una manera diferente lo que ya realizan con formularios normalmente, será confuso y en el fondo será también peor para ellos.

[surtich]

Yo creo que el enfoque no debe ser si existe una librería que solucione un problema concreto, sino si tiene sentido y es útil que Iris resuelva este problema.

Muchas de las librerías MVC de Javascript son capaces de manejar bindings bidireccionales. Pero tienen el doble problema de la eficiencia y la introducción de lógica en el template.

La idea que yo propongo es una forma sencilla y eficiente de pasar información del template al presenter de manera recíproca a como el método self.inflate pasa datos del presenter al template.

El caso de la validación es uno de los posibles usos pero no el único. Dices que esto se puede hacer con el plugin JQuery validation pero no veo por qué no Iris no podría colaborar en esto también. Además hay casos en que no es necesario validación: TextArea, Chechboxes, Radios, etc.

Lo de saber si algo está o no oculto, es verdad que lo tenemos que haber hecho en el presenter pero la condición que establece si algo está oculto puede ser compleja y, a lo mejor, es más cómodo saber simplemente si un componente está oculto o no.