Allright, so I've always known that to instantiate a component using the createObject function, you have to provide the dot-delimited path of the component. Like so:
Today, I was looking through the ColdBox framework documentation and I came upon this line of code:
I thought that this couldn't be right because the getSetting("AppMapping") gives you the slash-delimited path from the root of your site to your app. So I tested out the code myself expecting to get an error and guess what -- it worked!
So then I thought I'd try just hard-coding the slash-path that is returned by getSetting("AppMapping"):
It still worked. Even though now the path was a combination of slashes and dots. So I went ahead and just hardcoded all slashes.
You guessed it -- works fine!
So it seems like using dots, slashes, or a combination of the two works. Is anyone else surprised by this besides me?
Jul 31, 2008 at 7:10 AM I have seen that before, but have been told by higher-ups that it is an "undocumented" feature and should be avoided. They probably use the "dot" notation to align more with standard package naming, but really , it is just a path that they need to locate a file. I wouldn't be surprised if the dot notation was converted to slashes under the hood anyway. But, that's just a guess.
Jul 31, 2008 at 8:13 AM That's good do know, Ben -- thanks.
Also, I just wanted to clarify for anyone reading this post that the getSetting() and getDataSource() functions in the code above are specific to the ColdBox framework and aren't general CF functions (and also don't really have anything to do with the point of the post).
Aug 5, 2008 at 7:48 PM I was a little surprised when I saw it the first time... though for me that's been a while... I still make a point of using dots... don't ask me why. :) Unfortunately because I suspect the server is just replacing n instance of . or a slash with a slash, you still can't extend ../component even though you can extend subdir/component if you want. But you can create a .cfc file with a cfinclude instead of a cfcomponent tag and use the include to target ../component... not only that, but you can even use variables in the template attribute of that include and it works. :) So don't believe what they tell you about extends being a "compile time attribute". It's a line of bull.
Aug 23, 2008 at 11:23 AM Interesting. I had known about the ability to use slashes, but I didn't know that you could mix the 2.
Sep 9, 2008 at 12:56 AM Strictly speaking they're not equivalent because CF sets the "type" of the object based on the createObject() call.
So if you have an argument type set as type="com.foo.bar" and you create an object as createObject("component","com/foo/bar") you'll get an error if you pass it in as an argument, even though they're really the "same".
You can see the difference by creating the two objects (one with dots, one with slashes) and dumping them and looping at the name it gives you.
Under the hood CF does just essentially convert the dots to slashes, but it also does some validation to make sure you've not added ../ and such.
@Ike
The compiler requires that the attributes cfcomponent on all be constant, and thus the extends attribute is too. This is because the compiler expands those attributes into constant expressions in the compiled class.
So extend="foo.bar" turns into:
String getExtends() { return "foo.bar"; } inside the compiled class. This is probably done for performance reasons, though I'd imagine it's more about consistency.
And while you can create a cfcomponent that cfinclude's another component, the result is not the same. The type is totally different because it takes the parent cfc path as the type, and it also totally ignores the cfcomponent attributes in the cfincluded page. The extends attribute in the included component is also ignored, as are the cfproperty's.
So while it "works" in the sense that you get the functions from the directly included cfc, you don't get any of the inherited functions, nor the right type, nor the properties. What you get is broken.