There's also a more general potential issue with name conflicts. If you
roll all your own CFCs then no problem, but if you start using third party
applications then you might have conflicts - using the web root method
you're not guaranteed to get the right CFC in that case.
I'm not sure I follow you. Could you elaborate on this? I don't see a way that my own CFCs and third-party CFCs would differ, and how this difference would affect them. Say this is my tree:
webroot/
page.cfm
foo_section/
page_in_foo_section.cfm
system/
bar.cfc...and say I download some CFCs that refer to each other as "com.foo_app.bar" and "com.foo_app.baz", because they expect a mapping of "/com" to go to wherever you drop these guys. Wouldn't this be fine?
webroot/
page.cfm
foo_section/
page_in_foo_section.cfm
system/
bar.cfc
com/
foo_app/
bar.cfc
baz.cfcI only see a naming conflict of they need a root dir called "system" like I already have, but that's the same conflict that would always exist if someone randomly names their stuff the same as yours.
As a side note, wouldn't this be a strong argument for distributing CFCs that refer to each other as part of a package?
--
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]
