RE: [CFCDev] CFC name vs. full path in returntype attribute

[John Farrar]

OK… that seems to match what I was thinking. If you extend a CFC that is not in the same package (path) then you need to set the full path with the cfc name in the type. Has anyone ever had this type of issue with inherited CFCs in the same package (path).   John Farrar   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kotek Sent: Thursday, December 15, 2005 10:33 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] CFC name vs. full path in returntype attribute   Sorry, that should say: But changing it to the full scope <cfargument name="config" type="ourproject.extensions.config"....> would eliminate the error. On 12/15/05, Brian Kotek <[EMAIL PROTECTED]> wrote: Some may be inherited, some may not be, but if they are inherited and the base CFC is not in the same directory, the full path to the base CFC would be specified in the extends attribute. Not much else I can say about it, except that a cfc that might say <cfargument name="config" type="config"....> would throw an error along the lines of "error accessing directory c:\projects\some_other_project\extensions" (where "some other project" is a totally separate project from ours). But changing it to the full scope <cfargument name=" ourproject.extensions.config" type="config"....> would eliminate the error. Since adding the full scope solves the issue it isn't a huge deal to me, but if anyone has any idea under what conditions this might happen, or why, I'd be interested to hear. Thanks.   On 12/15/05, John Farrar < [EMAIL PROTECTED]> wrote: Is this using an inherited CFC or what? Could you give just a bit more detail? You may be onto something but it also seems like there could be other issues at play.   We have had issues with deploying CFCs that are fully scoped to different configurations. Therefore if there is an issue it would be good to know how to deal with it. So any insight you have would be appreciated.   Sincerely,   John Farrar   From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Brian Kotek Sent: Thursday, December 15, 2005 9:56 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] CFC name vs. full path in returntype attribute   We've run into problems where for some reason a non-fully-scoped CFC used as an argument or return type started throwing errors. Instead of looking in the current directory for a match, it seems to start traversing the custom tag paths looking for a match. In the environment that the gov't runs, each project has it's own private sandbox, mapping and custom tag path, so as soon as the engine tries to look for the CFC in some other project it throws an error that it cannot read the specified directory. I'm not sure if the real problem is something in CF or something in the way the environment is set up, but whatever the case, using the full path solves the problem. On 12/15/05, Sean Corfield <[EMAIL PROTECTED]> wrote: On 12/15/05, William Langshaw <[EMAIL PROTECTED]> wrote: > I am wondering what kind of ill-effects can arise from NOT using the > CFC's complete type (path) in the returntype attribute. That is, using > > Returntype="Person" > > As opposed to > > Returntype="com.sitename.foobar.Person" I don't know what ill-effects can arise from using the shorter form. I tend to use the shorter form for returntype= and cfargument type= so that a CFC can be picked up and dropped into another directory without code changes (obviously the same cannot be said for returntype= and cfargument type= attributes that reference a different type). -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org