Basically just a single registry of all properties and top-level objects in the application. So any object can request a handle to the registry and recall any object or property it needs. In particular, it doesn't provide any sort of assistance to implementing the business logic beyond providing a simple way to access whatever object(s) you need for a given operation.
There are a few main benefits: 1) my entire app's layout (though not it's function) is laid out in a single XML file 2) I can extend any given class and immediately update the entire app by changing that one XML file 3) the init/configure method pair from Mach-II makes initialization of all the CFCs a lot cleaner (a single abstract class implements init to do the initialization and provides a no-op configure that CFCs can override as needed). No need to ever pass anything into a CFC as initialization arguments, because it can always get everything it needs from the registry (which is passed to the abstract init method). I should mention that I generate a significant amount of code programatically, so this type of abstracted architecture works very well for me. If you're familiar with FarCry and it's concept of types (a CFC with properties, that gets installed into the database and such), I've taken it a step further. FarCry uses a generalized set of DB access components (the FourQ API), which I didn't really like. I have something similar to FarCry's types, which are used to generate the DB tables, but I take it the next step and build custom DB components for each entity as well, so my data access layer is custom tailored to the specific types I'm using. Each of those different objects is then subclassed for any custom behaviour that might be needed and can't be generated automatically. cheers, barneyb On Wed, 16 Mar 2005 11:15:04 -0800, Paul Kenney <[EMAIL PROTECTED]> wrote: > Out of curiosity, what is the objective your code aims for? > > > On Wed, 16 Mar 2005 09:48:12 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > Take a look at the Tartan framework. It looks really confusing > > initially, but it takes care of inter-object relationship problems > > with a remarkable degree of simplicity once you get your head around > > it. > > > > I've also had great success with taking the configuration management > > objects (AppLoader, AppManager, ListenerManager, PropertyManager, > > etc.) from Mach-II, tweaking them to handle different object types > > (services, daos, etc. rather than listeners, filters, events, etc.). > > It's simpler than Tartan, and targetting a different objective, but > > its quite effective if you already have a functioning object model and > > just need an abstract way to wire it together. Tartan, just for > > comparison, is a framework for implementing the business logic as well > > as managing the various objects. > > > > cheers, > > barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:198999 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
