Alternatively you can just put the component name in the cfargument type attribute or cffunction returntype attribute. So instead of "com.company.app.User" you could just list "User" instead. This gives you some flexibility as to the path (aka "package") of the CFC is although if you have two "User" cfcs in different packages they would both be valid which you probably don't want. I don't see that as a major issue though. I'm not sure what the implications of this approach are for CFCs that inherit from another CFC though.
No matter which way you go, I would strongly consider getting a local development environment set up. The upfront investment will save you time and headaches in the long run. -Cliff On 3/16/06, Peter Bell <[EMAIL PROTECTED]> wrote: > I haven't seen anyone comment on the dev and live components. This is what > factories are for - so you can abstract implementation details like paths > from your calling templates. I rteally haven't played with it, but a > dependency injection engine like ColdSpring should allow you to do this kind > of conditional metadata at runtime (someone with ColdSpring experience > please correct me if I'm wrong!). If not, you do it yourself by creating an > object factory and putting the conditional logic in there "if Devmode then > ComponentBasePath = com.dev" > > Best Wishes, > Peter > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of dickbob > Sent: Thursday, March 16, 2006 5:43 AM > To: [email protected] > Subject: Re: [CFCDev] How to use returntype correctly > > > Hi Tom, > > Thanks for your comments... > > >> How do I reconcile the fact that the pathname must be a constant > >> value with the path being different between the dev and live > >> environments? > > > > You mean you have objects like > > com.wibble.fo.bar > > on live but something different in development ? Why ? > > Not all of us have the luxury of a different dev and live server so I > have... > > com.dev.wibble.fo.bar > > ...and... > > com.live.wibble.fo.bar > > ...for the two different code streams. > > Dickbob > > > > > ---------------------------------------------------------- > 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). > > 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). > > 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
