Application Specific Mappings Are Horribly Broken

written by Geoff Bowers on Friday, 7 December, 2007 @ 10:42 AM


Application Specific Mappings are a furphy and do not work as advertised in CF8. If you thought that Application.cfc mappings feature allowed you to override ColdFusion mappings you'd be wrong. cfimport, "extends" and "implements" do not adhere to application specific mappings as defined in Application.cfc.

As a consequence of the way ColdFusion templates are compiled, an Application.cfc mapping is not the same as an Administrator configred mapping.

Sean Corfield puts this eloquently:

They can't possibly: per-app mappings are a *runtime* construct attached to a notional CF application. <cfimport> and extends= are *compile-time* constructs applied to a specific file. You cannot possibly have the compile-time behavior of a file depend on run-time settings in another file - how could you use the same file (.cfm/.cfc and associated .class files) from multiple applications??

I think my biggest complaint is the way this was advertised -- ie. as an application specific cf mapping. Obviously it is not. You'll find the misinterpretation is very wide spread and the documentation does nothing to dispel the myth.

With respect to CFIMPORT it just repeats what was in CF7's doco. As for Application.cfc mappings... this set of comments tells it all.

isaac dealey said on Oct 11, 2007 at 5:29 PM:
There doesn't seem to be any mention of this.mappings for setting application-specific mappings in the Application.cfc anywhere in the Application.cfc reference -- or for that matter -- in the documentation anywhere as far as I can tell.

halL said on Oct 12, 2007 at 6:31 AM :
Isaac dealey is correct. The mappings variable was left out of the Application variables table. You can find information on using This.mappings at:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=appFramework_04.html

If you follow the link provided you get this summary:

These settings override the server-side settings in the ColdFusion Administrator for the specified application only. Specifying per application settings does not change the server-wide settings. To set per-application settings, you must first enable per-application settings on the Settings page of the ColdFusion Administrator. You then set the mappings or custom tag paths in the Application.cfc file.

Probably a language barrier, me being Australian and all, but it seems very misleading to a dumb yokel like myself ;)

Perhaps in hindsight, a compile-time config would have been more worthwhile.

 

Comments

  • Justin Carter - Gravatar

    Justin Carter on 07 Dec 2007 01:24 PM

    I also thought of it as a "per-application mapping" and assumed it would work the same way as a mapping configured in the CF Administrator... What Sean says about compile-time vs run-time makes perfect sense, but it's not obvious until it doesn't work and then you wonder why... It really *should* have been pointed out earlier on, or as you say perhaps implemented in another way, if only to avoid the confusion :P


  • Vince Bonfanti - Gravatar

    Vince Bonfanti on 08 Dec 2007 01:36 AM

    For what it's worth, per-application mappings in BlueDragon--via the CFMAPPING tag--do override mappings configured via the administrator, as you expected CF8 to do.


  • Andy Bellenei - Gravatar

    Andy Bellenei on 16 Apr 2008 09:37 PM

    We are finding difficulties using per app mappings with the system experiencing intermittant crashes where it is unable to create an object based on the created mapping. Saving the cfc of the object causes it to happen, after a few executions it goes away. Very strange.


  • ike - Gravatar

    ike on 26 Oct 2008 04:43 AM

    What Sean says about it being impossible is also untrue. The server controls when things are compiled and how - they could take all sorts of variables into account when they do that. The language itself is merely an abstraction - when it grabs the template and converts that into java bytecode, it can choose to do that in any way they want. I've heard this "it's a compile time directive" tripe on several occasions and I still don't buy it. And the more I dig into the language, the less sensible it becomes. Version 3.2 the onTap framework currently does two things that were both declared impossible because of this "compile time" nonsense. It doesn't do something similar to them, it doesn't do something that achieves the same ends -- it does *the thing* that was declared impossible. In fact, one of those is made possible by the other.


Make a Comment





Leave this field empty

Options:

Size

Colors