Ah... los composites son presenters... composite.:-)
Osea que todo el tema de la sesión lo maneja el presenter.
La session se puede manejar por afuera tambien, es independient del
Composite, pero este sabe tratar con sessiones.
session := (Server serverNamed: 'Bank Project') newSession.
session instancesOf: Bank satisfying: [:each | each name = 'ABN'].
En este caso no importa sobre que sistema de persistencia estas
trabajando, la session se encarga de todo.
El SessionComposite maneja el AtomicComposite para obtener el objeto, y
la session para persistirlo donde la session crea conveniente.
Sigo sin saber que son los conectores.:-/
Todo lo que me viene a la cabeza son los de VAST, pero poco tienen que ver aqui.
Los conectores es una jerarquia de clases que conecta el modelo de un
AtomicComposite con los elementos graficos del composite. Algo asi como
la que trae Dolphin pero para este caso.
Claro, porque lo resuelve "otro" y no el mismo modelo.
Depende la forma de trabajo. Una vez que termine el modelo (digamos un
90%) en ese momento empiezo a crear cada view para los AtomicComposite.
Cuando tengo la views creada el #markDirty desaparece.
Cuando trabaja por dentro del modelo lo tenes que mandar, pero cuando
estas haciendo esto seguramente estas inspeccionando para cambiar o
agregar algo, si te olvidas del #markDirty, NO es tan grave.
Pero en la aplicacion (que ve el cliente) no te podes olvidar, que ES lo
mas importante.
A mi me resulta super comodo trabajar asi, no importa donde voy a
persistir los datos.
Si es en OmniBase todo el asunto esta solucionado. Solo cuando estoy
cambiando algo tengo que tener presente el #markDirty, y te puedo decir
que casi nunca lo tuve que mandar. Ya que cuando la aplicacion esta
hecha cambias los objetos en los Presenter.
Y el modelo original toda la jerarquia del dominio queda liberada del
#markDirty, que esto ES lo mas importante para mi.
Mi pago por esto, acordarme de tener que mandar el #markDirty cuando
esto inspeccionando la aplicacion por dentro.
Pero te aseguro (probado en la practica) que de esta manera el
#markDirty pasa a ser un anecdota mas que un problema.
Lo que "mas" me molesta son los TestCase, que se hacen para el modelo en
la Image (que sirven para ReStore tambien) que cuando paso a modo OmniBase.
Pero con D6 este problema es historia. pq' escribis unas cuantas
transformations usando el Code Rewriter y ya esta.
Estas transformation te quedan para siempre, solo hay que ejecutarlas.
Otro tema es que OmniBase me ha demostrado ser bastante confiable, asi
que los test que corren en memoria tambien corren en OmniBase (solo
cambia es lugar fisico de los objetos). Por lo que los TestCase a veces
agrego alguno especializado para cada sistema perisistente. Este tambien
para mi es un problema menor.
Hehe, bien podría darse el caso de tener una homónima, tambien tengo
Patient's :-)
Ponele 3 iniciales de cada proyecto en el nombre de la clase. Hasta
ahora no tengo en una misma imagen dos proyectos, se puede hacer.
Despues de todo el #markDirty: se manda cuando el usuario presiona
#modificar.
Eso lo hace el EddtingObjectPresenter, que sabe manejar al
AtomicComposite, y cuando lo abro le paso una sesion como parametro.
Esta session le pertence al un presenter mas general alguna subclase de
SeesionComposite.
Tambien vas a tener que hacer una gerarquia para reportes y presenter
especiales, que se pueden manejar de forma independiente a este framework.
Saludos Bruno
PS:
server := Server serverNamed: 'Bank Project'. " devuelve aReStoreServer "
session := server newSession.
tR := Time milisecondsToRun: [session instancesOf: Bank satisfying:
[:each | each name = 'ABN'].].
session logout: false. " false aborta la session, true hace commit "
server := server becomeOmniBase.
session := server newSession.
tO := Time milisecondsToRun: [session instancesOf: Bank satisfying:
[:each | each name = 'ABN'].].
session logout: false.
Previamente tuve que haber ingresado lo objetos, pero es lo mismo en vez
de mandar #instancesOf:satisfying: mandas #add: a todo una coleccion de
objetos (con logout: true).
