I believe it works without any problems if you keep all your CFC's in the same directory. If for instance i have a factory in a parent directory, and i want to instantiate an object in a subdirectory, specifying only the name in the returntype without the full path doesn't work. At least it didn't work for me the other day. I'd suggest you check that out for yourself. You might be able to get away with it by using a factory for each directory that takes care of instantiating all the classes in that directory - that idea just occured to me. Not sure what problems i'd run into there tho'.
If you haven't done so, you might check out BlueDragon. They've implemented a new mapping tag that allows you to specify application specific mappings, and the final release of that update is out in a few days, i believe. It's a solution that's aimed squarely at the problem you're trying to solve. http://blog.newatlanta.com/index.cfm?mode=entry&entry=9FC194BA-D28D-7C53-4C3 F848A4BC5550D Then i think you wouldn't even need the dynamic bit here Obj = CreateObject('component', '#Request.SiteName#.Objects.Person').init(); you could simply use the same name for all your sites, for example: Obj = CreateObject('component', 'Site.Objects.Person').init(); and map Site uniquely for each application. As an aside, I'm wondering if ColdSpring can help here. As far as i've seen, the paths to each CFC need to be declared explicitly in the XML config file. If i needed a "drag and drop" style deployment as you describe (and i do), how could that be handled using ColdSpring? (on CFMX). Maybe i'm not thinking broadly enough and don't see it, but at a minimum, i would assume you'd need to go through the XML and rework each path statement to point at the new site location. That might not be so bad, as it's all there for you in one file. Back it up, a careful search and replace on a single file, and you're (hopefully) done. Would that work as i describe? >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of William Langshaw >Sent: Thursday, December 15, 2005 10:45 PM >To: [email protected] >Subject: [CFCDev] CFC name vs. full path in returntype attribute > > >I am wondering what kind of ill-effects can arise from NOT using the >CFC's complete type (path) in the returntype attribute. That is, using > >Returntype="Person" > >As opposed to > >Returntype="com.sitename.foobar.Person" > >Obviously, in a perfect world the complete path would be better as its >not ambiguous and CF can perform run-time type checking (as much as >possible for, which for CF isnt that much). We are considering an >application controlled by MachII that in turn can control many >different "sites" (e.g. foo.com, bar.com, baz.com) using 1 core >"MachII" framework (at the root) and then the root index.cfm does a >lookup on CGI.SERVER_NAME to do a lookup and include the correct path >to that site's mach-ii.cfm. The idea is that every site would then >have its own set of CFCs which all inherit from a Core CFC suite (so >each site can be customized). But for every site specific CFC it would >have to specify its complete path and this wouldn't be always known. >E.g. we want to be able to quickly make a new site and use it, so all >object creations would look like: > >Obj = CreateObject('component', >'#Request.SiteName#.Objects.Person').init(); > >That is, the system is purely dynamic. But now you can see that the >returntype would have to be just the CFC name and not a complete path >since that isnt really known. > >Are we going totally off the deep-end here? The idea is that we >develop 1 code-base to share amongst many different sites with a few >little tweaks here and there (done by extending core objects) but for >the most part they would all be same, except for the presentation and >view layer, obviously. > >Any ideas? > >Thanks in advance >/cody > > >---------------------------------------------------------- >You are subscribed to cfcdev. To unsubscribe, send an email to >[email protected] with the words 'unsubscribe cfcdev' as the >subject of the email. > >CFCDev is run by CFCZone (www.cfczone.org) and supported by >CFXHosting (www.cfxhosting.com). > >An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
