This is why my company doesn't use any of the major frameworks, most of our clients are on shared hosts.
That said, there's no excuse for hard coding CFC paths. At the very least there should be some kind of variable set to the path to your app's CFCs. The only exception to this, is that you can't put variables in extends declarations. It's lame but we usually keep base components in the same directory as their children because of this limitation. Personally I think the way CF references CFCs is about the most backward thing CF does. I know it's Java-esque, but in java it doesn't map to your directory structure. There should at least be a way of specifying a upward-relative path to a CFC, so you could inherit something that isnt in a directory below yours without clunky mappings. My $0.02 Kam -----Original Message----- From: Dave Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 10:25 PM To: CF-Talk Subject: Re: Frameworks in a shared environment The only way I was able to get MG running from a non-standard location was via the brute force method of replacing references to "ModelGlue" to "MyModelGlue" in the ModelGlue code. Some of the instances weren't obvious and were revealed only when errors were thrown when attempting to run the samples. I tried searching the MG mailing list (Topica sucks) and emailed Joe, but never found an alternative. As was mentioned having to repeat this process every time a new version of MG is installed sucks. And to be fair, I had to do the same thing with Mach-II too. Dave At 10:01 PM 2/22/2006, you wrote: >To stress that I'm not just picking on MG here, Mach-II shares this >issue - a "/MachII" mapping is required and reliance on this root is >coded into the whole core of the framework. CF on Wheels is even worse, >requiring mod_rewrite, Apache mappings and a CF mapping. > >I'm not sure if Fusebox does this, but it's irrelevant as the fusebox >method of writing parsed files to the "parsed" folder means that we >can't use it anyway (our servers do not allow write access apart from >within a set temp directory). > >I guess the solution is to hack through the MG code (as a first >attempt) and replace all the ModelGlue directory references to a >dynamic value that can easily be reset in one location, which will be a >fun exercise every time I want to update the core MG code to a new >version but at least it will only affect me and not everyone else on >the box. > >On 2/23/06, James Holmes <[EMAIL PROTECTED]> wrote: > > The line 12 example I posted earlier is the line that reads that XML > > file, so it can't instantiate the component to read its own XML > > config file. > >-- >CFAJAX docs and other useful articles: >http://jr-holmes.coldfusionjournal.com/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:233264 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
