What I'd Like To See In Blackstone: Request-based Mappings

Posted by Dan on May 25, 2004 @ 9:47 PM

Ok, in honor of Tim Buntel's new blog, I'm going to start a little series of blog entries entitled "What I'd Like To See In Blackstone." I'm going to start off the series with a feature I've wanted in the language since CF3 first came out and I started using CF-based custom tags, and that's the ability to create a request-based mappings.

I'd love to be able to create dynamic mappings on page request for both the location of custom tags and for general mappings—which would be especially useful for referencing components. What I'd love to see is a syntax like the following:

<cfmapping
    type="alias"
    logical="/com"
    path="c:\root\site\build\com\"
    />


<cfmapping
    type="customTag"
    path="c:\root\site\build\customTags\"
    />

In the above example, I would now be able to place custom tags in the c:\root\site\build\customTags\ folder and invoke them using the standard custom tag notation (<cf_customTagName>.) I'd also be able to map my component folder to a directory, which would then allow me to keep all my related components together with the code they belong to.

My personal preference is to try to create my code without any outside dependencies. I also like to write my code in a way that I can create two seperate directories and run instances of the code in each directory. This allows me to keep multiple builds of the same code running so that I can not only develop new code, but fix bugs in the old code—that's if my code had bugs, we all know I write bug free code that may have hidden "features" in the code. :)

Another issue w/mappings is that creating a mapping isn't always easy. If you're on a shared host or doing contracting work, you don't always have access to the administrator. This can make creating mappings problematic. I also don't like having my code be dependant upon an outside source (like a mapping in the administrator.) These mappings can change without your notice and can cause unexpected results. (I once had an ISP move my site to a new server, but ended up pointing the mapping to the wrong folder, but one that contained a backup of my code. Needless to say, I pulled out many a hair trying to figure out why my code changes weren't taking affect. I had them restarting the servers and all sorts of stuff until I found the problem.)

Server-based mappings also create an issue when implementing 3rd party CF software. A lot of the professional CF products I've seen require creating a CF mapping for them to work. This makes it extremely difficult to (if not impossible) to run multiple versions of the product on your server. This may be required if you're in the process of testing the code for production or if you need to keep the old software functioning.

Anyway, enough of my ranting. Please post your feedback on your opinion of this enhancement. If there's enough of an user demand, maybe Macromedia will take note and implement it.

Categories: HTML/ColdFusion

2 Comments

  • Nice idea! What do you find you're using mappings for? I'm not sure when this happened, but a couple years ago I have found I stopped having a need for CF mappings. It's made moving applications from one server to another very easy. But so would your dynamic mapping tag!
  • The main need for mappings nowadays is for components. I currently use a hack UDF so I can use relative paths w/my components, but that's not "officially" supported and could break.

    I've moved to using for all my tags, but I'd much prefer to use the shorter, easier to read syntax of instead of . Granted, using the relative path on the template attribute makes it absolutely clear on where the template is being invoked from, but I don't see that being a huge issue if you know to look for tags.

Comments for this entry have been disabled.