Re: [Papo-hackers] Como leo los datos de un obj PersonaABM desde otro objeto similar

[Federico Heinz]

On Thu, 2004-10-14 at 17:43, maram wrote:
> El problema es que si modifico un dato en PersonaABM, ahora al
> compartir el EC , se refleja en ReceptionABM, pero a nivel de EC !, no
> de pantalla...

Precisamente por eso mi "respuesta" (más bien replanteamiento del
problema) se dividía en dos partes: una, la visión del EC (que la
solucionaste a través del recurso de pasar el EC como parámetro a la
nueva pantallas), te resuelve el tema a nivel "model", pero no te lo
resuelve a nivel "view" (es decir, los cambios no se ven en pantalla).

Guarda, que con este tema de que le pasás el EC como parámetro de una
pantalla a la otra, podés generar un problema: ponele que hacés una
serie de cambios en RecepcionABM, pero no le hiciste commit aún. De
golpe el usuario se va a PersonaABM, hace algunos cambios, y aprieta el
botón que dispara el commit... ese commit va a parar al EC donde
RecepcionABM hizo ya algunos cambios, y por lo tanto no sólo se graban
los datos cambiados en PersonaABM, sino todos. Se puede resolver
pasándole a PersonaABM un EC hijo del EC de RecepcionABM. De nuevo,
guarda, porque eso quiere decir que si el usuario luego hace un rollback
en RecepcionABM, el rollback también va a incluir los cambios que hizo
en PersonaABM, y eso no necesariamente es lo que el usuario espera.

> al cerrar la pantalla de PersonaABM,no puedo notificar
> a ,ReceptionABM de los cambios, tal vez haya que hacer un controlador
> que las sincronice.

Precisamente esa es la segunda parte de mi replanteo, y tu respuesta es
correcta: a esto lo tiene que resolver un controller, ya que coordinar
el view con el model es precisamente el rol del controller. No tiene
otro. El tema ahora es ver cómo deben interactuar los controladores para
lograr el efecto que vos esperás.

La manera que a mí se me ocurre, por cierto, es la de delegación: Cuando
ReceptionABM lanza una pantalla PersonaABM, debería anotarse como
delegado del controlador de ésta, y responder a un mensaje estilo
"PersonaChanged(unaPersona)", que es enviado cuando el usuario graba los
cambios en PersonaABM. Cuando recibe este mensaje, el
ReceptionABMController se fija si está mostrando esa persona en algún
lado, y les avisa a los views correspondientes que se actualicen.

Si implementás algo por el estilo, podés evitar el tema de compartir el
EditingContext: cuando llega el PersonaChanged(), el controlador de
ReceptionABM antes de avisarle a los views que se actualicen le dice al
modelo que refaultee los objetos que fueron cambiados... y tenés lo que
querés, aún usando ECs distintos.

En realidad, me parece que acá tenemos que buscar algo más general, que
no requiera tanta interacción entre los controllers de las ventanas,
porque esto funciona bien para dos ventanas, pero cuando tenés más de
dos (un ReceptionABM que llama una ventana PersonaABM que a su vez llama
a una ventana DirecciónABM, que a su vez...), la cosa se vuelve medio
imposible de manejar.

¿Será que una especie de notificación general con la semántica "llamando
a todos los controllers: refaulteen estos objetos y actualicen los views
que los muestran" no es tan mala idea al final de cuentas?

        Fede

-- 
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

signature.asc
Description: This is a digitally signed message part