Stijn, So basically, what you're doing is isolating the apps from each other by containing them within a Singleton - did i get that right? "... from the cfc's in the BaseCFCPath ..." sounds like composition to me.
How do the paths get resolved properly when using extends, arguments ... ? Or are you using a flat directory structure? Sorry for being confused, but i really want to understand how others are dealing with this, especially when someone says they aren't having any problem ... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stijn Dreezen Sent: Wednesday, May 04, 2005 8:18 AM To: [email protected] Subject: Re: [CFCDev] Basic component inheritance path question Thats exactly how i do it as well. Paths like BaseTemplatePath and BaseCFCPath, as well as appName etc... get loaded from a xml file in a bootstraps loader, which will sequentially determine its own location, parse the xml file in its own location, register the application with appName in the server, load application-specific variables, closed lists and language packs from the cfc's in the BaseCFCPath and register them in a singleton, register session management, .... I have a good 1500 cfc's on 27 cf servers in 25 different countries, most of them with slightly different settings and i have no problem at all managing the cfc's or deploying new versions. They can simply run next to each other. It only takes 2 attribute in the xml file (BaseCFCPath and appName) to run them next to each other. Maybe there are better solutions, but this one is definity doing the job for me, where mappings would make my life a nightmare by now. Just my 2 cents. Stijn On Tue, 3 May 2005, Jared Rypka-Hauer - CMG, LLC wrote: > Nando... > > In colloqial terms, "evil" can mean anything from michievous to "I really > really don't like them" and I think the latter is close to Roland's meaning. > > Maybe I'm missing something here... and granted, I can see the benefit of > sharing a codebase across sites... but I've written anything I needed to > redeploy using the webroot as the base of the CFC's path. I haven't seen > anyone address this as viable/not viable as a solution. > > I think the best idea is to allow a variable as part of a CFC type so that > "#myapp#.lib.cfc.foo" is a valid type. If the directory isn't there, it > throws an error as if it couldn't find a file. > > Laterz, > J > > On 5/3/05, Nando <[EMAIL PROTECTED]> wrote: > > > > I haven't lived in America for 25 years, so i'm probably not up on the use > > of the word "evil" in everyday speech. But in my very direct experience, > > for > > those of us that are creating applications to be distributed on anything > > "less" than a dedicated server, server-wide mappings tend to create bigger > > problems than the ones they attempt to solve, and it's very possible you > > might not see it coming. > > > > On a larger scale, for all the reasons Roland lists, they limit your > > ability > > to create a viable business with what needs to be a plug and play > > application. I've got nearly 2000 instances of a mapping in our code base. > > And the app isn't THAT big. Once you start relying on CFC's, mappings, if > > you use them, are all over the place. > > > > I would add to his list that whenever you are forced to search and replace > > the mapping so you can install a separate instance on a server ... you > > make > > it "twice" as difficult to maintain your codebase across installations > > with > > bug fixes and improvements. That can get out of hand exponentially! > > > > To expand our business, either we're going to have to modify our codebase > > and move toward what Roland is doing, perhaps using a single directory for > > all CFC's so i can use inheritance. Or wait until CFMX has application > > specific mappings. > > > > We had a provisional offer to include our app within another much larger > > online service. They wanted it now. I backpedaled largely because of the > > mapping issue, and the deal fizzled. It might have fizzled anyway if i had > > gone for it, but i couldn't really take the first step forward. > > > > Is that evil? Well, let's just say it was a little unfortunate. > > > > > > > -- > --------------- > ------------------------------------- > Buy SQLSurveyor! > http://www.web-relevant.com/sqlsurveyor > Never make your developers open Enterprise Manager again. > > > > ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
