Yeah - that don't work. Actually it's because it doesn't work that
we're having this conversation. ;^)
However I'm not sure if just relative paths would really help all that
much (and could be bigger headaches), for several reasons:
When you're just instantiating or extending, it makes perfect sense, but
how would you standardized CFC type checking with relative paths? I
want to say (for example):
<cfargument name="User" type="Com.DepressedPress.Security.User">
"User" may be in the same package or not, could be lower or higher in
the directory structure. In one CFC I might have to do this:
<cfargument name="User" type="../User">
while in another I might have to do this:
<cfargument name="User" type="Security/User">
In the end I'd rather not have to know where it is physically every time
I use it as an argument. I DO want to know that I'm getting my user and
not somebody else's tho. ;^) I use CFCs as argument values a lot and
love the auto type checking - but I want it to stay simple.
Similarly you'd have to define rules for inheritance that I think would
end up loopy no matter what. When a component inherits from another,
does it use the root components path or it's own as the base? Does each
maintain their own paths for their own methods? Even if the methods are
overridden?
What if you call "super" with a CFC as an argument? Something like (not
a good, but at least a legal example):
Super.new(CreateObject("Component", "MyCFC"))
Would the relative reference to "MyCFC" be from the child or the parent?
If the parent then validated it would it use the path from itself or its
child?
This could get very complicated when dealing with Facade patterns and
other redirection/obfuscation techniques as well.
I would dearly love to see some elegant for dealing with fully qualified
paths on a shared environment, but I really think there's a definite
need for fully qualified, rather than relative, paths.
Jim Davis
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Jeffry Houser
> Sent: Thursday, November 13, 2003 5:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Why we need the ability to use a path to specify
the
> location of a CFC we want to call (long)
>
> At 10:19 PM 11/13/2003 +0100, you wrote:
> >Years ago, the ability to use <cfmodule template="../myTag.cfm">
solved
> two
> >problems regarding custom tags:
>
> I know you can use:
>
> <cfobject component="MyComponent" name="ComponentResult">
>
> When the component is in the same directory. I thought you could
use:
>
> <cfobject component="../MyComponent" name="ComponentResult">
>
> Just as easily.
>
> Am I missing something?
>
>
>
> --
> Jeffry Houser, Web Developer <mailto:[EMAIL PROTECTED]>
> Aaron Skye, Guitarist / Songwriter <mailto:[EMAIL PROTECTED]>
> --
> AIM: Reboog711 | Phone: 1-203-379-0773
> --
> My Books: <http://www.instantcoldfusion.com>
> Recording Music: <http://www.fcfstudios.com>
> Original Energetic Acoustic Rock: <http://www.farcryfly.com>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the word '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]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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]
