On 25/10/12 00:55, luiz americo pereira camara wrote: > - Initially i questioned the fpc obsever support, now i see as a good > implementation
The FPC Observer and Mediator is based on works found in the tiOPF framework - done a few years ago. And that in turn was based on a implementation I done for our company back in 2005. The design and functionality has a long history, is well tested in production software - so yes, it is good. ;-) > - ... (i would bet it was introduced to support the Live > Bindings) Yes I would imagine so. The tiOPF Observer & Mediator implementation is the basis for our company's "live bindings", which we call Model-GUI-Mediator (very similar to Model-View-Controller). This was long before Delphi had Live Binding support. We have been using the tiOPF implementation for 7 years in all our products, and all our application's UI is Observer/Mediator driven. There isn't a single DB-aware component in sight. I can hook up any gui control to a data/business object property with a single line of code, and have 2-way updates with no extra work. Michael even took the tiOPF idea and built a non-tiOPF based design-time support for Lazarus (this is where the current FPC Observer/Mediator comes in) - though the design-time code was never contributed to the Lazarus project. I'm sure he will at some point. Anyway, to make a long story short. The current FPC Observer/Mediator is a good design and very flexible with what it can offer. The Lazarus project could very easily use this to implement their own "live bindings" support. It could even make DB-aware components obsolete (optional). > (two implementations) since would > have overlapping features with possible overhead (two observer lists per > component?) at base classes Yes indeed, having two implementations in FPC would definitely not be a good idea! Graeme. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel