El 6/10/05, Bruno BB (st)<[EMAIL PROTECTED]> escribió: > > > >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']. Ok, viene a hacer como un broker de objetos. > 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. Me hace ruido lo de AtomicComposite, me suena a "blanco negruzco" :-) Pero es una cuestión de comprensión y de heredar el nombre seguramente desde Dolphin 4. > >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. ¿Equivaldrían a los AspectAdaptors pero marcando el markDirty cuando algo se "setea" mediante ellos? > >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. Comprendo y concuerdo. > 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. Aca no entiendo. Osea... ¿cuando testeas lo haces con objetos "ya persistidos" o asumiendo que la persistencia es transparente? > >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. Pongo dos para algunas, tres para otras, un vicio que vi en VisualAge y frameworks como OmniBase, Restore, etc. Ahi vienen bien los namespaces. > Despues de todo el #markDirty: se manda cuando el usuario presiona > #modificar. ¿Y marca dirty todo, o sólo el cluster principal? > Eso lo hace el EddtingObjectPresenter, que sabe manejar al > AtomicComposite, y cuando lo abro le paso una sesion como parametro. Hasta aca bien. > Esta session le pertence al un presenter mas general alguna subclase de > SeesionComposite. Esto no lo entendí. > Tambien vas a tener que hacer una gerarquia para reportes y presenter > especiales, que se pueden manejar de forma independiente a este framework. Si... bueno, para eso falta aun. > 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). Esto me hace inferir, tal vez ingenuamente, que el ODBTree lo tenes con clave por cada clase, y luego el modelo navegable, de manera de acceder a las instancias de las clases directamente y luego comenzar a traer todo a partir de allí. Gracias por los comentarios, seguiré preguntando hasta que me ponga a hacerlo. :-) Saludos. -- Esteban A. Maringolo [EMAIL PROTECTED]
