I know there are Macromedians on this list -- any of you care to give us
some insight here? Is it really something like Mark opines -- a random
implementation decision, or are there solid reasons for the choice?
For instance, not having variables in extends makes "sense" because it's
a compile time issue. It's nice to "know" these kinds of things,
especially for something that seems like such an obviously "good thing"
(given that we can already use relative paths "down" the tree it's clear
that MACR didn't decide relative paths in general are bad to use).
Educate us.
- Nathan
Mark Mandel wrote:
I would hazard a guess it goes something like
extends="object.Name"
Where the '.' is replaced by '/'
When it goes to some sort of fileResolver, it goes as a '/' notation.
('object/Name.cfc')
So when you put in '/', it doesn't get replaced, and it works just fine.
However, if you were to put in '../../object', it then get's turned into:
'//////object' which will throw an error.
I agree it would be a good solution to alot of problems.
Mark
On 6/9/05, Nathan Dintenfass <[EMAIL PROTECTED]> wrote:
Have we ever had a satisfying explanation for why we can have relative
paths "down" the directory tree but not "up" the directory tree?
That would solve this problem (and many others) without needing dynamic
run-time evaluation of CFC paths.
----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
