-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Diego Gomez Deck escribi
Hola Gallego,
2006/12/20, Diego Gomez Deck [EMAIL PROTECTED]:
[...]
Diego, muy interesante tu trabajo. No creo que siempre sea necesario,
esn todo tipo de sistema, notificar al modelo de los cambios en la
vista inmediatamente, -Tenes pensado tener algun modo tipo
"desconectado" hasta que se hace
un submit? -
-Tenes pensado dar soporte para transacciones y buffer de modelos?
La forma m s f cil (y creo, m s limpia) de hacer esto es instanciar
OTRO
objeto. Si es una modificaci n, se puede clonar el objeto original,
editar el clon, y actualizar el modelo (desde su clon) at micamente.
Lo bueno de esta forma es que tanto el objeto "InEdition" como el
original, son modelo completos... ergo se aplica toda la l gica del
modelo.
Cuando se crea un objeto nuevo, tambi n se instancia una versi n para
edici n... que no se ingresa al sistema hasta que est
aceptado/validado.
Esto trae bttes complicaciones cuando el modelo no es "escalar" por
decirlo de alguna manera, osea... un objeto que conoce a otros
objetos, que conoce colecciones, etc, etc. Bufferear todo eso es muy
costoso, y los editores no te quedan "transparentes" a esta situaci�n,
llegando a puntos donde para validar o mostrar algo haces:
aBuffer modelCopy foo
...pues #foo de aBuffer no responde lo que deber�a.
Algo que cuando puedo hago es lo opuesto, cuando el usuario "Agrega"
algo, inmediatamente se crea este algo con el m�nimo estado posible y
v�lido. Entonces esto simplifica la tarea de los editores, pues el
objeto no es "transiente", sino que ya es real en el sistema, por lo
tanto puede interactuar como tal.
Es como cuando en windows creas un nuevo archivo, te crea un "New Text
Document.txt", y recien ahi podes editarlo.
Esto dispara otro hilo interesante, paralelo a este:
- C mo manipular los objetos con estados intermedios/inv lidos?
- Se permite la instanciaci n de objetos inv lidos?
- C mo se refleja, en el modelo, que algunas partes
de un
objeto son obligatorias?
Si les parece, podemos charlar un poco sobre esto.
En lo personal pienso que el objeto debe poder colaborar con
un 3ro que es un validador, que justamente valida que el estado
del mismo sea consistente.
Lo de las partes obligatorias pueden ser definidas por este tercer
validador tambi�n.
Osea... se pueden tener validadores "at�micos" (por ej que un string
no tenga m�s o menos de tantos caracteres, o no incluya ciertos
caract�res,etc) o macro, que abarquen a todo el objeto, incluyendo los
resultados de las validaciones de estos valores.
El ejemplo que siempre surje en estas discusiones es si un piano tiene
aCollection de teclas, si aCollection esta vac�a, el piano es un
piano? En mi opini�n s�, es un piano sin teclas, asi como un auto sin
ruedas es un auto, a�n un auto a mitad de camino de su proceso de
ensamble sigue siendo un auto.
Saludos.
- --
Esteban, que no es v�lido ni consistente :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
iD8DBQFFinvQdPDJq/J5MioRAu77AKCDOfPKaGTp2sG/z5jElRVu3b+clgCfZOFO
5VhQ3E3N5cPSe8rIXxbPYfk=
=CY7w
-----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque est� suscrito a Grupo "clubSmalltalk" de
Grupos de Google.
Si quieres publicar en este grupo, env�a un mensaje de correo
electr�nico a [email protected]
Para anular la suscripci�n a este grupo, env�e un mensaje a [EMAIL PROTECTED]
Para obtener m�s opciones, visita este grupo en
http://groups-beta.google.com/group/clubSmalltalk?hl=es.
-~----------~----~----~----~------~----~------~--~---
