Thanks for the support Kerry. I'm going for the "every instance is an island" approach.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Kerry > Sent: Monday, September 12, 2005 10:11 AM > To: [email protected] > Subject: RE: [CFCDev] Factories and mappings > > > Nando: > > "So to have more than one instance of an app on a server > puts you through some gymnastics. Either you have to search and > replace the > mapping name in your CFC's" > > Or not rely on any mappings! > > "Going down the directory tree works, it's just going up where > you run into > problems." > > True, but I found that by architecting the app / packages with > this in mind, > the problems arent too great. > > "The only limitation i can think of is that components that employ an > inheritance relationship would need to be in the same directory > or the child > would need to be lower" > > Actually, Im not sure that relative inheritance works at all, it > doesnt seem > to on my 6.1 test box. > Initially I was a big fan of inheritance, but I have since reduced the use > of inheritance as much as I can in my apps, because it seems to be a much > less flexible solution than composition. And where I have used it, it is > same directory inheritance e.g. > > /formcontrols > formcontrol.cfc > dateselect.cfc (extends formcontrol) > fileselect.cfc (extends formcontrol) > > > Bill / Barney: > > "we have architected it in such a way that the core files that > are the same > across all > instances are installed in one location using using a standard named > mapping" > > I can certainly see the value of this approach in terms of code > maintenance, > but personally, I have avoided it because a product we use / resell is > architected this way, and upgrading versions always breaks a lot of > customised code, as a reaction against this, I have chosen more > of an "every > app instance is an island" approach, so that everything the app > requires is > bundled into itself. > This does create a bit of a maintenance nightmare, but in our case, its a > good trade off, as it means we can run as many versions as we like > simultaneously on one cf instance, and any new version does not have to be > tested against every install to make sure it doesnt break anything. > > > > > ---------------------------------------------------------- > 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). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
