On Wed, 4 May 2005, Nando wrote: > 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?
Exactly > "... 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? No During runtime, I always have a unique path to each method in each cfc, wether it be static (in the application singleton) or in a instance (in the session, to which i have a pointer in the application singleton). During compile-time (extends, datatypes, ...), for the naming, i have the luxury to be able to use the same directory, which is very unlikely to change. I must say i rarely Extend, and i only do it if i know for sure i can use a fixed path (so i wont extend cfc's that are deeper in the three past the point where i need a variable, for example an application name. I have a number of cfc's which are quite generic and which i DO extend often (QueryManagers, Caching Managers, Logging, ...) which don't belong to a specific application, and are available to all applications with a hardcoded path (int.eu.consilium.common, while application-specific cfc's reside in int.eu.consilium.#appName#) into the appName cfc scope. I'm sure it has a name, but i'm not good with OO terms and i am only using patterns for 2 years, so i'm still a noob,and i dare not put names on it, chances are high i'd label it wrongly. I hope it makes a little sence what i'm saying, its hard to explain if you don't master the OO/dp vocabulary very well. Cheers, Stijn > > 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] > > ---------------------------------------------------------- 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]
