>It's fine if you use a mapping or use fully qualified names -
>but not so fine if you don't.
>
>The problem is eliminated if you use fully-qualified names (as
>in your "com.foo_app.bar" example). But if the external app
>just called "bar" then you might have conflicts.
The problem is also eliminated if you use something that can only be a
relative path.
e.g.
<cfset myObject = createObject('component','lib/somecomponent')>
Because you've used '/' as the delimiter and the path doesn't start with a
'/' it must be a path relative to the calling template.
>
>Remember that CF caches its references. So if you called just
>"bar" then CF caches the location of that. If you try to call
>a different "bar" then you'll get the first one, not the "closest" one.
Only if there isn't a component called bar.cfc in the directory of the
calling template. That's always the first place it looks.
If you only use relative paths of the form 'folder/subfolder/component' and
calls where the calling template is in the same folder as the component you
can build complex apps without ever needing to create a ColdFusion mapping
or worrying about name conflicts.
One restriction is that methods that return component instances need to
specify only the component name rather than the fully qualified path.
This still leaves you with some difficulty if you want to create an instance
of a component in a parent directory, or a sibling directory. You can
normally work around that pretty easily by having a hierarchical structure
with a single app manager cfc that lives at the top of the directory
hierarchy. Any component that needs an instance of a component it can't
instantiate itself gets it passed in as an argument.
I have used this approach pretty extensively on some projects and have found
very few limitations or problems.
Spike
--------------------------------------------
Stephen Milligan
Code poet for hire
http://www.spike.org.uk
Do you cfeclipse? http://cfeclipse.tigris.org
----------------------------------------------------------
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]
