Skip to main content
Inspiring
January 30, 2014
Question

Is it just me or are this.mappings acting funny?

  • January 30, 2014
  • 13 replies
  • 2816 views

Let me preface this: The following code is in the pseudo-constructor of my application.cfc (outside all functions) and this is the FIRST run of the application (so the application has not yet initialized)

With that being said, I wrote the following code:

<cfset this.mappings[ '/model' ] = expandPath( '/path/to/models/folder' ) />

To make sure it took, I dump it:

<cfdump var="#directoryExists( '/model' )#" />

And sure enough I get: YES.

Remove the dump and add the following code:

<cfset myConfig = new model.utils.Config() />

And CF errors out telling me it cannot find a Config.cfc.  Well, I verified.  In that 'models' folder, there is a 'utils' folder and a 'Config.cfc' in there.  If I instead change the line to read:

<cfset myConfig = new path.to.models.folder.utils.Config() />

Then it works fine.  So in essence, the mapping is not working.  I have an odd feeling that this is all due to the fact that I'm doing this in the pseudo constructor area, but if that's the natural place where you define this-scoped variables, I would think this is OK.  I know the application.cfc is LIKE a CFC, but in some ways different.

Well, if I create a this-scoped variable in some other CFC file, I can immediately reference the variable and value on the life after, even in that CFC's pseudo or in the INIT before I perform a <cfreturn this /> 

I'm trying to understand why the mapping is not working.  A problem I have is that the returntype attribute of my Config.cfc is 'model.utils.Config', and this errors out when I use the 'new path.to.models.folder.utils.Config()' method, understandably because they're different FQDNs.

    This topic has been closed for replies.

    13 replies

    Inspiring
    January 30, 2014

    *** UPDATE ***

    Well, one of those funny things happened.  I came to realize that my understanding of expandPath() is wrong.  After having used it in a manner that was not as the function intended (but the result worked), I have now realized that this fluke needs to be resolved to a point where I can understand how expandPath(), directory/fileExists() and CFC dot notation works alongside CF mapping.

    I've been at this problem for about 4 hours now and nothing has made any sense.  The documentation provided by Adobe raises more and more questions and all the local testing I've been doing (where I'm ADAMANT a file exists and am being told it does not, and when I do something that should not exist, I'm being told I pathed to it properly).

    In these situations, it's always best to leave the problem alone and hit it again tomorrow from a fresh perspective, so I'm admitting a defeat with an asterisk for the time being, but I'll get at this again tomorrow.

    Carl Von Stetten
    Legend
    January 30, 2014

    I think I've seen others express problems with trying to use a mapping elsewhere within the pseudo-constructor, so you might want to try avoiding that.

    I'm guessing this is related to a previous thread on this forum where you talked more about your myConfig process.  I had done something similar in Application.cfc myself (albeit without a CFC file).  I read in an XML config file in the pseudo-constructor, parsed it, and inserted the "this" variables.  I then read the same XML file again in the onApplicationStart method and parsed out the "application" scope settings and inserted them.  Eventually I moved all the "this" stuff out of the XML file and hardcoded it in the Application.cfc file.  Why did I do this?  Because the pseudo-constructor is run on every request.  So on every request, my application was opening and parsing the XML file and rewriting the "this" scope, all of which added unnecessary overhead to my application.

    HTH,

    -Carl V.

    Inspiring
    January 30, 2014

    @Carl-

    I guess in the desire to build an automated application (cause let's be honest, how cool is it when you have a config file that controls how the application inits, am I right?), it seems you are where I might be heading.  I just didn't want to have to resort to static simplicity due to the fact that I couldn't comprehend a built-in function or how ColdFusion's mapping worked.

    I did consider the performance hit from doing the XML parsing every route.  In my application, after the initial heavy load of the startup, on each request, the pseudo runs a:

    Config.processAppPseudo()

    This iterates over a private structure variable in the object that contains all the key/value pairs (previously pulled from XML) and simply executes a <cfset structInsert( this, keyName, keyValue, true ) /> in a loop.  It's overhead, but an acceptable level I feel.  And if need be, I could have part of the startup BUILD a file dynamically created that has all the this-scope declarations.  To me, I just wanted any automated solution that did not resort in me hard-coding the variables.

    Inspiring
    January 30, 2014

    <cfdump var="#fileExists( expandPath( '/path/to/models/utils/Config.cfc' ) )#" /> <!--- This dumps YES. --->

    <cfset this.mappings[ '/model' ] = expandPath( '/path/to/models/' ) /> <!--- Same as c:\web-root\path\to\models\ --->

    <cfdump var="#fileExists( expandPath( '/model/utils/Config.cfc' ) )#" /> <!--- This dumps NO. I've yet to figure out why. --->

    CF documentation states that fileExists() should work with in-memory addresses, but I don't know if that means 'mappings'.