Skip to main content
A
Aegis_Kleais
Inspiring
October 8, 2012
Question

Setting THIS-scope in the onApplicationStart

  • October 8, 2012
  • 2 replies
  • 2457 views

Having an issue that doesn't make sense to my understanding of how CF (10) works.  My app is as dynamic as I can make it.  Right now, there are no <cfset THIS.applicationTimeout> (or any other application variable) existing outside the application.cfc's methods.

What I do is run code outside those methods that checks if the application exists.  If so, it iterates through an APPLICATION variable and, per request, sets those THIS-scope variables.  But on the initial startup, this exact same function is done in the onApplicationStart() method.  It iterates through and creates the THIS.<application_variable_name> = <value> declarations.

After doing it, I even immediately dumped THIS and saw things like "SessionManagement" = "true" (usually defaults to 'NO').

Yet I'm getting issues down in the onSessionStart which state that I have not enabled by SESSION scope (I checked the CF ACP and Session Variables ARE enabled).  So is there some kind of logic I'm failing to see here why this isn't working?

I'm half-expecting that CF would have to say 'YES' when dumping the THIS.sessionManagement variable...

    This topic has been closed for replies.

    2 replies

    A
    Aegis_KleaisAuthor
    Inspiring
    October 8, 2012

    Hey Adam.

    Well, I definitely am looking for a "Eureka!" moment here (in other words, I would love to COMPREHEND why CF is not working as I expect)  Though right now I can't say I've gotten to that point.

    As it stands right now:

    <cfif isNull( APPLICATION )>

    <!--- Set THIS.name to a hash of the current template. --->

    <!--- Set a default processing directive, like disabling debug output. --->

    <cfelse>

    <!--- Process this var, APPLICATION.config, which stores values that can be evaluated and set into the THIS scope's application variables. --->

    </cfif>

    Of course, in the onApplicationStart(), which to my knowledge, runs once after the isNull( APPLICATION ) code fires off, also does the same logic that the <cfelse> is running ONCE it has populated the APPLICATION.config structure (which is a struct that holds lots of info, including the application variables)

    So, I was thinking "OK, traditionally, application.cfc THIS-scope info goes OUTSIDE methods.  And I am setting those THIS-scope application vars INSIDE the oAS().  This might be the essence of my problem.  CF cannot set THIS-scope variables to an application that has its name defined only IN the oAS() method.

    Am I barking up the right tree?

    A
    Adam Cameron.
    Inspiring
    October 9, 2012

    To be honest, what I find myself thinking when I read what you're trying to do is "WTH don't you just write your code the way an Application.cfc is intended to be written, and just don't try to do what you're doing".  Why don't you juse leave the this-scoped stuff in the pseudo-constructor where it belongs, and set the application stuff in onApplicationStart(), session stuff in onSessionStart() and request stuff in onRequestStart().  As is the intention of Application.cfc

    It might be useful to read this:

    http://adamcameroncoldfusion.blogspot.co.uk/2012/08/more-on-applicationcfc-when-things-run.html

    And this:

    http://adamcameroncoldfusion.blogspot.co.uk/2012/07/difference-between-events-and-event.html

    At best, there's a chance that some stuff that's supposed to be in the this-scope might work if it's not set in the pseudo-constructor, but no other scopes' stuff is available there.

    Why are you trying to do things differently from how they're intended to be implemented?

    --

    Adam

    A
    Aegis_KleaisAuthor
    Inspiring
    October 9, 2012

    The "More on Applications..." article spoke WELL above my head about constructors and pseudo-constructors.  I couldn't follow it.  The "Difference between events..." article iterated on something that I was aware of (but there was a time I wasn't)  Many CF books/articles iterate that "You can CALL onApplication/Session/RequestStart but it doesn't Start it, it merely runs the code that is in there.

    In answer to your question, I think because what I'm doing is trying to develop a custom framework.  To me, a framework provides the backbone that multiple applications can run off of.  So, I originally had all the application's app variables defined in the app-config.xml, which the application.cfc would load up and process in order to dynamically set those when it loaded up.  I'm trying to marry simplicity with low-maintenance

    I guess, a less elegant solution might be to have the application.cfc simply include a defined .cfm page that statically defines that THIS-scope settings for the application .cfc.  Yeah, it's an additional HTTP call, but I guess I'm doing this because I want to ensure that between multiple applications on this framework, they are all using non-customized application.cfc files.  You know, 1 application.cfc which can dynamically integrate with the framework and then loadup files that are SUPPOSED to be different per-application (like their configuration files).

    There are so many methodologies and best pratices that I seem to be learning as I go (which I admit, is not the best way to learn), and this has been a learning experience in and of itself.  I try to ensure that my code doesn't over-complicate things, but it might be natural for that to end up as such if I don't know better methodologies to get what I'm looking for.

    A
    Adam Cameron.
    Inspiring
    October 8, 2012

    I think you'll find CF needs those variable values to associate the incoming request with an application & session before any of those event handlers are run.

    The mere fact that you end up with variables having values is possibly neither here nor there... the values need to be in place when CF needs them, which is at the point in time the pseudo-constructor is run.

    What you're doing is equivalent to this pseudocode:

    Does myVar exist?

       if so do [something important]

    [more code]

    set myVar

    check if [something important] happened

        no it didn't, but if I dump myVar, there it is

    And from that get puzzled as to why [something important] didn't happen, because you can see myVar sitting right there in front of you.  But you've set it after it was needed.

    --

    Adam

    A
    Adam Cameron.
    Inspiring
    October 8, 2012

    Oh wow... the forums really munged my code there.  But you probably get my drift.  Sorry about the formatting.

    --

    Adam

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices