45 respuestas en este tema

[Delphius]

Asi es Agustín. Formalmente, en el sentido más purista, debería encararse esa mediación por un Proxy al menos.

Es cierto que existe LiveBinding. Se la ha promocionado mucho.
Hasta donde yo sabía LiveBinding usaba un mecanismo similar al que utiza el DataSource y los controles dbware, que en parte se vale de una implementación de Observer.
Pero como no contaba con una versión de Delphi reciente no podía hechar una mirada profunda.

Inicialmente al post anterior lo tenía pensado hacer más largo, comentar sobre el uso de Proxy como una mejor alternativa a ese ejemplo muy básico.
Lamentablemente recibí una llamada importante y tuve que dejar el post lo más breve, simple y directo posible.

No se si ahora vale la pena ampliar lo que dejé escrito antes.

Desconocía que además de LiveBinding hubiera otro mecanismo de comunicación. Más material de lectura. ¡Deja de ponerme tareas che!

Saludos

[egostar]

..... Desconocía que además de LiveBinding hubiera otro mecanismo de comunicación. Más material de lectura. ¡Deja de ponerme tareas che! ....

Nada, nada, a trabajar que ésto se pone bueno

saludos

[Agustin Ortu]

Pues LiveBinding tambien usa Observer y RTTI, y con ello crea enlaces como los que vos comentas. Estos enlaces son entre propiedades que creo que tienen que cumplir ciertas caracteristicas, asi como tambien las dos cosas que queres comunicar, es decir, las tres cosas estan relacionadas

 

Hay enlaces que son DataSet <-> Control "Lista" (ListView, TreeView, Grid, ListBox)

Otros son DataSet <-> Control "Campo" (Edit, CheckBox, RadioGroup)

Otros directamente Propiedad "Componente" <-> "Propiedad Componente", por ejemplo, se puede establecer un enlace entre un ComboBox.ItemIndex <--> DataSet.Filter 

 

Luego el enlace puede ser unidireccional o bidireccional. Por ejemplo, si modifico el ComboBox.ItemIndex, donde el elemento del ComboBox refleja el "filtro actual utilizado en el DataSet", quiza me interese que si programaticamente modifico la propiedad DataSet.Filter se actualice tambien el ComboBox, o no

 

Para prototipados es excelente. Hay "DataSets" por decirles de una manera, virtuales, que te dan Data random usando generadores, desde strings, a integers, fechas, imagenes. Con eso uno puede ir diseñando la aplicacion sin tener implementado todo lo de abajo, y luego se instancia una clase que conecta con el modelo real

 

A mi mucho no me gusta. Demasiada RTTI que lo hace lento, los enlaces son por nombre de propiedad, es decir, en string, lo cual no lo "agarra" un refactoring; algunos han intentado usar atributos, pero esto es más RTTI, y el resultado tampoco es del todo satisfactorio. Luego, quierase o no, LiveBinding esta medio implementado siguiendole la pista a lo que ya existe que es enlace a datos, es decir, DataSet, DataSource y compania, por lo cual los objetos que intervienen parecen que hablan mas el lenguaje de DataSet que el de un verdadero modelo de objetos. Si bien podes enlazar "cualquier cosa", ese cualquier cosa en realidad se logra utilizando Adapters, osea, es como si yo mapeara los TPlayer en un TClientDataSet y luego lo conecto a un DBGrid. 

 

Yo creo que este tipo de cosas es mejor hacerlo uno mismo, porque seguramente se va a amoldar mejor, ya que uno es libre de diseñar como quiera. Cuando empece a aplicar un poco de MVP quise intentar una solucion "generica" y la realidad es que cuando mas especificas y al grano son las interfaces, mas facil diseñar, desarrollar y utilizar

[escafandra]

Yo creo que este tipo de cosas es mejor hacerlo uno mismo, porque seguramente se va a amoldar mejor, ya que uno es libre de diseñar como quiera. Cuando empece a aplicar un poco de MVP quise intentar una solucion "generica" y la realidad es que cuando mas especificas y al grano son las interfaces, mas facil diseñar, desarrollar y utilizar

En ocasiones uno puede perderse diseñando mentalmente asuntos y tratar de abstraerlos consiguiendo implementaciones complejas que se salen de la necesidad real de origen.

Para el caso de este tema yo hubiese definido la estructura TPlayer y quizás un TListPlayer que se encargaría de crear y destruir la lista y puesto que parece que no hay más necesidad, no complicaría más el asunto. Me plantearía si la lista necesita cambiar el número de elementos y si estos pueden ser insertados en el medio, si fuese necesario, pensaría en un TList o similar, en caso contrario, la lista la podría manejar un simple array dinámico como miembro del TListPlayer. Utilizaría el TComboBox para guardar referencias a cada TPlayer de la lista, pero no serían destruidos ni creados por él, simplemente transportados para guardar el orden de los Items. Este punto quizás ni fuese necesario (no conozco las necesidades concretas que llevaron a enecumene a ese diseño, cambio de órdenes en ítem...). Si no hubiese más necesidades, aquí terminaría mi diseño de esta parte del problema, y a otra cosa.

 

 

Saludos.

[Delphius]

Nada, nada, a trabajar que ésto se pone bueno

saludos

 

Jefecito, comprenda es que ya tengo suficiente trabajo  

 

Pues LiveBinding tambien usa Observer y RTTI, y con ello crea enlaces como los que vos comentas. Estos enlaces son entre propiedades que creo que tienen que cumplir ciertas caracteristicas, asi como tambien las dos cosas que queres comunicar, es decir, las tres cosas estan relacionadas

 

Hay enlaces que son DataSet <-> Control "Lista" (ListView, TreeView, Grid, ListBox)

Otros son DataSet <-> Control "Campo" (Edit, CheckBox, RadioGroup)

Otros directamente Propiedad "Componente" <-> "Propiedad Componente", por ejemplo, se puede establecer un enlace entre un ComboBox.ItemIndex <--> DataSet.Filter 

 

Luego el enlace puede ser unidireccional o bidireccional. Por ejemplo, si modifico el ComboBox.ItemIndex, donde el elemento del ComboBox refleja el "filtro actual utilizado en el DataSet", quiza me interese que si programaticamente modifico la propiedad DataSet.Filter se actualice tambien el ComboBox, o no

 

Para prototipados es excelente. Hay "DataSets" por decirles de una manera, virtuales, que te dan Data random usando generadores, desde strings, a integers, fechas, imagenes. Con eso uno puede ir diseñando la aplicacion sin tener implementado todo lo de abajo, y luego se instancia una clase que conecta con el modelo real

 

A mi mucho no me gusta. Demasiada RTTI que lo hace lento, los enlaces son por nombre de propiedad, es decir, en string, lo cual no lo "agarra" un refactoring; algunos han intentado usar atributos, pero esto es más RTTI, y el resultado tampoco es del todo satisfactorio. Luego, quierase o no, LiveBinding esta medio implementado siguiendole la pista a lo que ya existe que es enlace a datos, es decir, DataSet, DataSource y compania, por lo cual los objetos que intervienen parecen que hablan mas el lenguaje de DataSet que el de un verdadero modelo de objetos. Si bien podes enlazar "cualquier cosa", ese cualquier cosa en realidad se logra utilizando Adapters, osea, es como si yo mapeara los TPlayer en un TClientDataSet y luego lo conecto a un DBGrid. 

 

Yo creo que este tipo de cosas es mejor hacerlo uno mismo, porque seguramente se va a amoldar mejor, ya que uno es libre de diseñar como quiera. Cuando empece a aplicar un poco de MVP quise intentar una solucion "generica" y la realidad es que cuando mas especificas y al grano son las interfaces, mas facil diseñar, desarrollar y utilizar

 

No eres el único que se ha planteado hacer su propio mecanismo de mediación. Yo también he hecho experimentos, más simples. Al patrón MVP lo esquivo. El motivo es que a pesar de que entiendo su fundamento, como que no me cuadra al momento de su puesta en implementación.

Prefiero un enfoque más simple, el uso de objetos "links" me parece dentro de todo KISS y que cumple con el propósito.

 

En ocasiones uno puede perderse diseñando mentalmente asuntos y tratar de abstraerlos consiguiendo implementaciones complejas que se salen de la necesidad real de origen.

Para el caso de este tema yo hubiese definido la estructura TPlayer y quizás un TListPlayer que se encargaría de crear y derruir la lista y puesto que parece que no hay más necesidad, no complicaría más el asunto. Me plantearía si la lista necesita cambiar el número de elementos y si estos pueden ser insertados en el medio, si fuese necesario, pensaría en un TLits o similar, en caso contrario, la lista la podría manejar un simple array dinámico como miembro del TListPlayer. Utilizaría el TComboBox para guardar referencias a cada TPlayer de la lista, pero no serían destruidos ni creados por él, simplemente transportados para guardar el orden de los Items. Si no hubiese más necesidades, aquí terminaría mi diseño de esta parte del problema, y a otra cosa.

 

 

Saludos.

 

Así es amigo. Siempre en lo posible hay que mantenerse lo más simple posible. Yo he sugerido como alternativa el uso de esos objetos "links" pero no son estrictamente necesarios si podemos valernos de nuestra clases "Lists" y que tengan métodos de búsquedas y maneras de referenciar a instancias dentro de ésta.

Veo útil el modelo "link" cuando la cantidad de objetos a manejar es muy grande, y se necesita un acceso más rápido e inmediato que una búsqueda.

Aún con los mejores algoritmos y aprovechando las estructuras de datos adecuadas localizar elementos tenemos órdenes lineales como O(log n) empleando árboles AVL) mientras que acceder al elemento en cuestión basado en enlaces es O(1) ya que los tenemos vinculados y no hace falta buscarlo.

 

Saludos,

[Agustin Ortu]

Ahora que lo recuerdo, aca hay un ejemplo de estos controles "presentados"

 

http://delphiaccess....-currency-edit/