One thing to keep in mind based on what you're suggesting is that, as far as I know, you can't call a CFC directly without telling it what method you want to use. That is, if you request a CFC via HTTP without specifying a method CF will intercept the request and send you to the documenter code (and prompt to login if you are using admin security).
I doubt you'll have any browser problems -- it's not like browsers are programmed to recognize ".cfm" anyway (let alone the many different extensions that live out there). An alternative to consider is to use a single .cfm as your entry point "controller" -- it can then call the appropriate CFC (which you can then cache in memory, saving you all those instantiations) controller and call the right method. That will give you more flexibility to process the request itself in ways you probably can't even anticipate now before passing the "clean" call to the right method of your CFC (which you can still do dynamically via CFINVOKE rather than needing a switch statement) -- it also means your CFC doesn't necessarily need to include the views -- all the methods of the controller CFC could, for instance, return some kind of lookup to the view which you can then handle on your .cfm page (perhaps with a separate CFC that does nothing but manage views). Given the logic flexibility, ability to take advantage of CFC caching, and the lack of the ability to set a "default" method in a CFC this might be a better choice. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Ben Curtis > Sent: Tuesday, June 01, 2004 3:04 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] submitting to .cfc > > > > We're considering pointing all links and form submissions to a cfc > Controller. The cfc uses cfparam to set a default method to use in case > none is passed, and after all processing is complete it cfincludes the > appropriate .cfm View. Basically, what was a large cfswitch at the top > of a cfm page is pulled into a separate file and broken into functions > (enabling much more interesting processing flows). > > But all links and form submissions end in .cfc. Some browsers used to > discern the mime-type from the file extension--do they still? There > doesn't seem to be any other file type with that extension, but you > never know. Are there any other hidden gotchas I'd want to know about > before investing a lot of effort into this? > > -- > > Ben Curtis > WebSciences International > http://www.websciences.org/ > v: (310) 478-6648 > f: (310) 235-2067 > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
