To get around this whole issue one CAN use returntype="any" (and even returntype="struct" works for OBJECTS, yes objects!). We got our code to "work" this way but it feels like a total kludge. Whether its a distant possibility or not, what happened if one day Macromedia upgraded CF and made it stronger typed, then all code that relied on returntype="any" would crash and burn, right?
My colleague's attitude is that "returntype="any" works, lets just run with it and if Macromedia pulls the rug under us one day, we will deal with it then". My attitude is to do it right the first time, but it might not even be possible (our goal is to build a complete CMS solution where one can add "sites" on the fly, they all get driven off a mapped core set of CFCs but then there are customized CFCs that live under each site and we need to find a way to have these CFCs have "flexible" returntypes since we dont know what those are ahead of time, e.g. drag-and-drop site creation/deployment.) My ultimate question is: how "safe" and "reliable" is using returntype="any"? Is it a big performance hit too? /william On 12/16/05, wolf2k5 <[EMAIL PROTECTED]> wrote: > On 12/16/05, Nando <[EMAIL PROTECTED]> wrote: > > I believe it works without any problems if you keep all your CFC's in the > > same directory. If for instance i have a factory in a parent directory, and > > i want to instantiate an object in a subdirectory, specifying only the name > > in the returntype without the full path doesn't work. At least it didn't > > work for me the other day. I'd suggest you check that out for yourself. You > > might be able to get away with it by using a factory for each directory that > > takes care of instantiating all the classes in that directory - that idea > > just occured to me. > > I verified this: if you can safely use the short name as > return/argument type if you keep all components in the same dir, but > it won't work if you have components in differents dirs. > > Regards. > > > ---------------------------------------------------------- > 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]
