Moving to CF10, Need help with Application.cfc

If each "subapplication" has a different name (e.g.: <cfset THIS.Name = "StudentServices_stdLoad"/> ), then they will each have their own sessions separate from any sessions created by the root-level Application.cfc.  So any session variables you set in OnSessionStart() in the root Application.cfc will not be seen from any pages within the "subapplication".  In order to share sessions, all "subapplications" must use the same name as the root-level Application.cfc.

Just as an aside, in the future please strip down the whitespace when you post code to review to reduce the amount of scrolling required.  It will make it easier for others to examine and offer help.

-Carl V.

@alecken,

Can't speak to the how the whitespace gets generated.  I guess once you submit a message, if you see a bunch of whitespace, you can go back and edit the message to remove it.  It's not a big deal if there is whitespace, it just makes it harder to read the code.

With regard to the root Application.cfc vs. sub-application Application.cfc and THIS.name, it can be a bit confusing.  It might be easier to think about it going from the top level down to the lowest level. 

An "application" has a unique name that defines it as separate from all other applications running on the same ColdFusion instance.  If your applications use sessions (and not all applications have to), each application will have it's own collection of sessions effectively walled-off from any other application's sessions.  If you change the THIS.name in Application.cfc (from here on out I'll refer to it as App.cfc for brevity) and hit a page in your application, it starts a new application on the ColdFusion instance, and will have a new session collection.  So, in your case, if your sub-application App.cfc defines a different THIS.name from the root App.cfc, you start a completely new application on that ColdFusion instance, and a new session collection.

It looks to me like what you really want is all sub-applications to share some common settings, but still operate independently from each other.  Can you confirm whether this is your goal? If it is, I can think of a different way to make this work that will allow each sub-application to operate as an independent application.

One other thing, and this may just be a copy/paste error - in your sub-application App.cfc, the <cfargument> tags following your onSessionStart() function should be inside the function and immediately after the <cffunction> tag.

-Carl V.

OK.  It sounds to me like you really shouldn't be using a single root Application.cfc at all, if all you want to do is share some settings between your "sub-applications".  I would look at storing the common settings in an external file that all of the applications can read in.  The simplest way is to put the settings in a .CFM file somwhere outside of the web root (so it is not directly web accessible) and load it with <cfinclude> tag into the OnApplicationStart() method of each sub-application's App.cfc.  That .CFM file can be as simple as:

<cfset application.myCustomSetting = "blahblah">

<cfset application.myOtherSetting = "foo">

Alternatively, you can look at using a config file like this Ray Camden blog post suggests, and use the GetProfileSection(), GetProfileString(), and SetProfileString() functions as needed within OnApplicationStart().  You could even put ALL of your settings in

A third option is to store your settings in an XML file or in JSON format in a text file.  You could then write code to read in the XML file, and use something like xml2struct.cfc to convert the XML into a struct, then append the struct to your application scope.  If you go the JSON route, then just read in the JSON file and use DeserializeJSON() to convert it into a struct, and append it to the application scope.

What I think is probably the best approach is to use a community-supported MVC framework like FW/1 or ColdBox (maybe you already are, I don't think you've said so though).  One of the many advantages to doing so is that they have built-in "environment" support that can be used to configure common settings, depending on your environment (dev/qa/production).  You would handle reading in your external settings through the "environment" mechanism.

One other thing to think about: your login mechanism.  I think you want to use one set of login tools that is shared by all of the "sub-applications".  You can do this also by putting the login/authentication-related code somewhere outside the webroot of your applications, and then either set up a mapping to that location in CF Admin, or set an application-specific mapping in your various App.cfc files.  That way all the "sub-applications" share a common set of code for the login process.  I don't know how your login process works (do all users go to the same login page then get redirected into their relevant "sub-application", or does each "sub-application" have a discrete login page that utilizes common back-end processes to authenticate and redirect), so you'll have to judge how that is best accomplished.

Hopefully this gives you some useful ideas.

-Carl V.