News from the Lists: Intro and sharing app scopes across apps
One of the cool things about Alagad (in fact it was one of the things that attracted me to work here) is that we’re strongly encouraged to be involved in the community surrounding any of the technologies we work with. That includes mailing lists, and mailing lists often bring up topics that make excellent blog fodder… so from now on I’m going try to start getting something from the lists up weekly. It may be a link or two to some cool threads, it may be the body of one particular email. This week, I’m going to use the body from an email I sent and was encouraged by a couple people to convert to the blog.Someone wrote in to the ModelGlue list with the following scenario:
- non-ModelGlue application in the webroot
- ModelGlue application at /admin
- MG app needs to modify data in the application scope of the app in the webroot
The question being asked was how to accomplish the task of updating the application scope of the application at / from the app at /admin. He was going down the road of using ColdSpring and having a bean factory in the application scope for the app at / and applying that as the parent bean factory to the ColdSpring instance in ModelGlue in the app at /, but he had some questions about how to get the application scopes to talk to eachother. my answer follows: Based on what I’ve read from your posts, you’ve got more going on here than just needing a parent bean factory. If you need to share the application scope between two completely separate applications, you basically have three choices, but since one of those choices is a nested ModelGlue application (aka subapplication) and one of your applications is not using ModelGlue, you actually only have two choices. They are, in no particular order:1) Single Application ScopeIf you want to keep these two applications running against different application scopes, you’re going to need to get sort of creative. OTOH, if you don’t mind them sharing application scopes (like there’s not going to be some horrendous name collision), all you really need to do is have 2 Application.cfc files, and put the administrative application where-ever you want. ColdFusion will join the application scopes together and app 2 will have access to app 1’s application scope variables. On the off chance I’m completely crazy, I just tested it… and it works. The only proviso is this: if you hit app 1 first, then onApplicationStart() for app 2 won’t fire… so you’ll have put something in onRequestStart() to check for something in the application scope (like application.app1inited and application.app2inited) and call onApplicationStart() manually (with the correct double if statement). I recommend doing this in each app so that it doesn’t matter which one starts first, the other one will run right.The nice thing about this approach is that ModelGlue gives you an easy way to apply a parent bean factory to the captive beanfactory instance it owns… just edit the index.cfm file for the MG application and uncomment the line that sets modelglue_PARENT_BEAN_FACTORY. Change it to something like this:
<cfset modelglue_PARENT_BEAN_FACTORY = application.beanfactory />That’s it, that’s all. Since they’re not both MG apps, there shouldn’t be an issue with 2 instances of ColdSpring, the MG framework (and you can change the name of the framework in the application scope via index.cfm if you need to… check the comments there) and whatever else the non-MG app needs in the application scope. I can’t think of any reason this won’t work.2) Separate Application ScopesIf you really really need this thing to work wtih different application scopes, you’re going to need to do something like this in App 1’s onApplicationStart():<cfset server.apps[application.applicationname] = application>Then in your MG app, when you need to reload the CFC in App 1’s application scope, just do something like this:<cfset server.apps.app1.varName = createObject("component","some.foo.path.to.Object").init()>where the string literal "constants" is replace by the actual name of the application scope variable that contains the CFC full of variables that app 1 needs. If you need to enable 2-way communication between these applications, then just add <cfset server.apps[application.applicationname] = application> to app 2’s onApplicationStart() as well, so you could call things back and forth between them.Another way to do this is to use Application.cfm with your MG app and leave off the name="" attribute. Do that, then dump the application scope. Shocking, no? [NOTE for blog: You really should try this, and never EVER use shared hosting again, anyone.] Anyway, it’s one way to make sure that an application has access to the application scopes of every application on the server. Great for server control apps and stuff… but at this point I don’t think it works with Application.cfc (when you leave off the name, stuff gets really messed up with Application.cfc).Anyway, just deciding to use hierarchical bean factories isn’t enough for your situation… you need to either have 2 apps with the same application name or you need to provide a way for applications to cross the application scope boundaries… there’s only 2 ways to do that and I’ve just hilited both of them. Frankly, there aren’t many disadvantages either way, so I don’t think either one is superior. Personally I’m always looking for opportunities to use the server scope, so I’d probably have my applications register with the server scope… but that’s just me and only cuz I think it’s the cooler of the 2 options. 
