Sean, This is a very useful example. Thanks for sharing! This has always been a sticky situation for developers to navigate, and I've seen a lot of not-so-elegant hacks, including some I've written myself :) At my last company, we had a fairly simple solution that worked well for our use case. We had a ServerInfo.cfc, which resided in the main custom tags folder, so it could be instantiated without a mapping from any app on the CF instance. We not only had dev/qa/staging/production identifiers (such as isDev(), isStaging(), etc. methods), but also a number to identify which box it was on in our production cluster -- this was primarily useful for debugging, but I think it also assisted with some dynamic reloading and such. There were just a handful of properties set in the init method. We stored a ServerInfo.cfc.template in our repo and deployed a different version to each environment/ server. This of course required a slightly different file for each server, but it very rarely changed, so it worked out well.
I just remembered one other tid-bit that worked well with that ServerInfo.cfc setup... We had a lot (30+) of related apps, each with one or more domain name that we stored in a database. We were also able to leverage ServerInfo.cfc to implement a getHostByDomain() type method, which accepted the production domain name (from the DB), checked current environment, and returned a properly formed host name. Something like... if production, return arguments.domain else if staging, return 'stg.' & arguments.domain else if development, return 'dev.' & arguments.domain etc. The other benefit was to not need to do any host sniffing to identify the environment (plus this wouldn't tell us which box it was in a clustered environment). I guess we combined the environment/server info into one small CFC. That said, I really like the way you have all environment settings neatly set in one place and you can deploy the same file to all environments. If I were to do it again, I might separate these properties and have both an EnvironmentService.cfc and a ServerInfo.cfc. Anyway, just thought I'd throw it out there. Thanks, Jamie On Apr 26, 7:02 pm, Sean Corfield <[email protected]> wrote: > This is a bit more work but it's very flexible: > > Write an "environment service" component that is initialized with a > map in ColdSpring that contains the settings for all tiers with host > name matches for each (and a default development map). The environment > service gets the server hostname and finds the matching map at > startup. All code that depends on environment values has the > environment service wired in as a dependency and fetches configuration > values from it. > > Here's some snips of the way we had it set up at Broadchoice: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
