New Blog: Flash Weakness

Just got this via CFAUSSIE.

http://notflash.blogspot.com/

A whole blog complaining about the shortcomings of Flash and its IDE.

For those that use Flash, this is probably a good resource, and for those that don't, it's a pretty funny read.

Enjoy :o)

Relative CFC Typing and Extending (CFC WTF Part 2)

So I had my big winge about CFCs being able to create other CFCs relatively, but not being able to extend or use return or cfargument types relatively, and how it totally messes up code being truly reusable.

So I'm chatting to Spike about this issue, and he's looking at my post, and he casually remarks to me: 'Well, why don't you try '\' rather than '.'?  See what happens".

I of course thought to myself, no way is that going to work.. I mean, it's just silly. It doesn't even look like a real class name definition.

Well I'll be damned (and several other loud expletives I echoed at the time), it freakin' works. And to top it off, it works relatively. Spike came up with the good once again.

So to make myself clear through all this muddle - you are perfectly able to:

• createObject("component", "com\level\Cat")
  - i.e. create Dog.cfc in the folder com\level folder relative to where you are calling it.
• <cfargument name="Cat" type="com\level\Cat" required="true">
 - i.e The type of the argument is of the Cat.cfc up in the com\level folder relative to the CFC this is in.
• <cffunction name="getDog" access="private" returntype="com\Dog" output="false">
- i.e The return type of the function is of the Dog.cfc up in the com\ folder relative to the CFC this is in.
• <cfcomponent name="Dog" extends="level\extend\Extend">
  - i.e. extend the component Extend.cfc in the relative directory of level\extend to the CFC this is in.

This is really big thing as it means that you can relatively go down a folder tree with your inheritence and typing with CFCs. You can't actually go back up (least I haven't found a way), but you can go down it.  This means, you have much more ability to write really portable code - as long as you are relatively careful (no pun intended) about how you structure your packages.

for example - if I have a directory structure of:

• \webapp\a.cfc
• \webapp\one\b.cfc

i can now make a extend b without going back to root and/or a mapping via:
<cfcomponent name="a" extends="one\b">

As well as do similar things with type and return values on cfargument and cffunction.

Here you can download my relative pathing testbed so you can test it out for yourself, and see all the possibilities.

Quite frankly, this has opened up a whole lot of interesting things in terms of how I want to structure my code, and whether or not a cfmapping is even required when doing CFC development.

No cfmapping - how cool is that?