You should check out Mach-II, which takes a much more reasonable approach to the single point of entry than Fusebox ever did, IMO.
I think you could easily make single CFM that is very lightweight but still gets you the control you are looking for (which is not to say I am personally advocating a single point of entry at all, but if you want that, I think you might have better luck in the long term with a .cfm -- the caching of the CFC alone would convince me). > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Ben Curtis > Sent: Tuesday, June 01, 2004 4:31 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] submitting to .cfc > > > > Thanks for the response, Nathan. > > > > 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. > > We set a default in the Controller.cfc that all controller cfcs extend: > > <cfparam name="Form.method" default="doControl" /> > > > > 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). > > I think this question is just a case of me testing the theory that you > can never be too careful. So far, it seems to hold up. :) > > > > 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. > > This is an interesting variation--essentially removing the common > Controller functions (receiving the incoming request and delivering the > resulting view) to a facade or proxy-like beast. My team and I have > been reluctant to funnel everything through a single central point, > partly because we often work independently and shared files scare us, > and partly because of bad experiences with such files becoming ungainly > huge. It also seems like a bumper shot, bouncing off one file when your > target is another. But it could help us standardize and validate > certain tasks a well-behaved controller ought to do, like preparing the > Request-scope data struct the View expects to have delivered. > > Food for thought. Thanks. > > -- > > 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]
