It does make sense... but I'd still like to figure out a way to circumnavigate the CFINCLUDE issue without rebuilding the app from scratch. ;^)
I'm actually (as I suspect may CFers are) trying to add some CFC-based features to an existing procedural application. In the end the session manager and much of the foundational elements will be CFC-based but the presentation and content will still be procedurally-based. So it isn't an "OO" implementation (or at least not fully), but it is a CFC implementation. ;^) Another problem is that CFCs just don't lend themselves all that well to full OO implementations. A simple example is that if I use inheritance to create the components as you suggest CF doesn't allow me to do automated type-validation. The application, now, heavily relies on type validation. If I expect a component of type "CFC_DepressedPress.Framework.DP_Session" I CAN'T pass a component of type "CFC_DepressedPress.Framework.DP_Session4SQLServer" - even if the latter IS an extended instance of the former. I think my first option (a dedicated broker object instantiated with each business object) is the "most OO" of the bunch - and does allow for type validation during composition at the business-logic layer. But it also duplicates the methods in both the parent and the broker (unless I want to call the broker directly whenever I need the method). I dunno... maybe I'll still give it a try, but the lack of type validation will be a huge pain the ass. Jim ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
