I've been contemplating it too. I took a good look at my code base and i like your previous statement more and more ... that probably the best approach is a composite of compromises. a CofC, if you will ... ;)
I still have to do some experimenting to make sure everything works, but right now i'm staying with dot notation, and if possible i'm going to retain some packages - grouping any cfc's that are related via inheritance together so the child obj's can find the parent. I still have to experiment to make sure it will work, as i don't have enough experience with this yet. And yes, the folder will be at the root level of the application. If application specific mappings happen, it'll be fairly easy to make the change, as most of the code affected will be in the Factory(s). Application specific mappings have been asked for in an enhancement request for some time. Not sure where to go and add my voice to that if i haven't already. I asked for them in Tim Buntel's "Scorpio" blog as well. http://www.buntel.com/blog/index.cfm?mode=entry&entry=F1341353-4E22-1671-5B9 119B7EA89AD6F > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Mark Mandel > Sent: Wednesday, September 14, 2005 5:41 AM > To: [email protected] > Subject: Re: [CFCDev] Factories and mappings > > > I'm actually sitting here contemplating the above issue. > > Looking at the frameworks that currently abound (mach-ii, Tartan, > Model-glue etc) they all have one thing in common - they all have to > be installed by dropping the folder at the root level of the > application. > > I'm starting to lean very much so in that direction. It has it's > drawbacks (as outlined in the above post), however it seems to be the > *most* flexible of options, and in MOST cases you will always have > access to the root of your domain or can create a mapping to that > directory. > > That being said - I can already see places where the above method is > going to cause me huge grief on the corp intranet I work on sometimes. > > At the end of the day - I've been bitching about this issue for long > enough, it really sucks, and I don't understand how MM have got away > with it for so long. But all we can do is work around it. > > Regards, > > Mark > > On 9/14/05, John Farrar <[EMAIL PROTECTED]> wrote: > > Well... I don't do everything the same way. Generally my only > extends are > > from packages, and haven't had the issue you guys mention. Perhaps my > > childlike innocence is preventing that because I approach > things different. > > Sorry, that surely isn't going to help you resolve your style > of CFC usage. > > I will try to follow the thread and see if a creative concept > comes to mind. > > (I am still a supporter of adding just a little more "UMF" to the next > > version of CF CFCs.) Nando is quite creative... and I am so flooded with > > overflow right now... and meeting my deadline for SOS v3 that I > am checking > > this whole thread out to see if there is ways to do the very > thing. (In fact > > another CFer has me motivated to build a methodology inside SOS > that will > > allow Rails features for application building. I am amazed with the cool > > possibilities of implementing at least some of the concepts as > they fit best > > to our language. Working on Active Record concepts right now. I like the > > concept of data intuition. Not sure if that should be added in the > > methodology level or the site level yet... lots of angles to consider.) > > > > John > > > > P.S. > > I can remember when no one seemed to be using CFCs, and now it > seems people > > use them exclusively to the neglect of tags. (NOTE: not > suggesting to solve > > the issue with tags.) > > -- > E: [EMAIL PROTECTED] > W: www.compoundtheory.com > ICQ: 3094740 > > > ---------------------------------------------------------- > 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]
