Problema de sincronización utilizando .ajax() y .submit() de jQuery

Estándar

Trabajando con jQuery me encuentro con un error en mi código que al principio hizo que me arrancara algunos mechones de pelo de mi cabeza ;).

Resulta que estaba escribiendo una función “callback” para el manejador de evento .submit() de jQuery asociado a un formulario. En el cuerpo de dicha función debía completar automáticamente un campo de acuerdo a valores ya introducidos y obtener un documento JSON desde el servidor con mas datos y en conjunto finalmente poder completar el campo. Para esto último necesitaba usar .ajax(). Y mi odisea empezó…

Por alguna extraña razón la llamada al servidor nunca llegaba a destino y la función “callback” error de .ajax() era invocada pasando un parámetro de error con valor 0. WTF pensaba.

Luego de un tiempo de probar y probar me di cuenta que no le daba tiempo a .ajax() para ejecutar su llamada al servidor ya que la función .submit() retornaba demasiado rápido. Teniendo en cuenta que por defecto .ajax() es asincrónico, pasando como parámetro async: false solucioné el problema.

Anuncios

Controladores flacos, Modelos gordos y Vistas tontas

Estándar

He llegado a la conclusión que cuando uno implementa el patrón de diseño MVC en una aplicación es una buena idea crear controladores que sean muy simples, modelos en donde resida la mayor parte del código, y finalmente vistas con código solamente relacionado con la muestra de datos al usuario y disposición (layout).

Algunas recomendaciones

Acerca de los controladores

Deberían consistir (en lo posible) en muy poco código, el suficiente como para responder a eventos (donde corresponda), dirigir el flujo de la aplicación de acuerdo a los estados de las entidades modelo invocando métodos dispuestos para tal fin, configurando la vista y poco mas de acuerdo a las necesidades.

Acerca de los modelos

El grueso de la aplicación debería residir en ellos: desde la lógica de negocios (obviamente ;)) pasando por la validación y hasta generación de vistas en base a su estado interno para estas ser entregadas a los controladores de acuerdo lo soliciten. Esto último no significa que los modelos deban generar y administrar la interfaz gráfica por si mismos, sino que deberían mantener alguna clase de referencia a mecanismos que lo hagan por ella, de manera de no exponer la información privada del modelo hacia otras partes de la aplicación, manteniendo el encapsulamiento, facilitando la refactorización y el reuso de código.

Es importante aclarar que solo los modelos pueden alterar su estado interno. Exponer un atributo privado mediante un método setter, sin que cumpla otra función mas que la de asignar un valor a dicho atributo, es equivalente a hacerlo público, por lo tanto es una mala practica de diseño. Por ejemplo: en vez de que un controlador use el siguiente pseudocódigo:

empleado.set_sueldo(empleado.get_sueldo() + (porcentaje * empleado.get_sueldo() / 100))

para modificar un sueldo sería mejor escribir

empleado.modificar_sueldo(porcentaje)

siendo porcentaje un entero positivo o negativo.

Acerca de las vistas

Solo deberían encargarse de la visualización del estado de los modelos utilizando lógica para tal fin pero para nada mas. Hay que mantenerlas bien simples y desprovistas de lógica en la medida de lo posible.

En fin

Lo expuesto anteriormente representa mi humilde opinión basada en la relativamente poca experiencia que tengo desarrollando software. Toda la información que he leído hasta ahora me hace pensar que no hay una única forma de implementar MVC y que el patrón puede y debe adaptarse a diferentes contextos de ejecución y lenguajes.