Kees wrote: I think that if you do it that way you will need to create object just for about everything and you will keep switching between the bridge interface and you own objects.
Hi Kees I'm glad you're thinking along the same lines, but I disagree that the objects will be specific - the idea is to use metadata to configure the extended objects and store that in the DB. I know there's a common thread of storing all configuration in xml files - but for real-time object creation, I prefer the config to be in the DB. The idea is to forget about the bridge interface completely and provide an interface to all supporting functions through the generic extended object interface - even for "simple" objects. I'm suggesting to configure logical objects and forget about the physical objects completely once that is done. Easier said than done - maybe, but that's the intention. Once this is done, the relations between the logical objects corresponds to methods and events in the "real world" (as it were), which can trigger/implement business logic. I think this view is even more abstract than what you have done, so it could possibly exist as a base class. I'm trying to build a framework for my applications, rather than extend the toolset - if I can make that distinction. For me, the toolset (which includes the bridge interface), should exist in the base classes rather than in the application - which should have underlying services which deal with all the physical issues, whilst the application deals with only the logical. cheers Emile _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
