-
-
Save woods/4d4af26fb91f51d73c72 to your computer and use it in GitHub Desktop.
# A helper for determining which partner site we're on. This can be | |
# used for setting a CSS class on the body tag in the layout, or | |
# for referencing namespaced assets or translations. | |
def parner(host=request.host) | |
if $ENV['PARTNER'] == 'graduate' || host =~ /graduate/i | |
'graduate' | |
elsif $ENV['PARTNER'] == 'schreyer' || host =~ /schreyer/i | |
'schreyer' | |
else | |
# decide whether to fail or default to one of the above | |
end | |
end |
Interesting. Yeah. You're really making me reconsider this…
I could totally see where perhaps you'd never want to do URL matching; where instead you'd always want it to be a conscious decision via a required environment variable. The README would instruct you to start your development rails server with an ENV. And the error message if it's not set could be very instructive.
Perhaps our URL matching was born out of a desire for convenience, and perhaps that's misplaced.
Good food for thought!
def partner
ENV['partner'] or raise "You must set the PARTNER environment variable to either 'graduate' or 'schreyer'"
end
Perhaps that would be more robust. Then our servers would be locked in too. They're currently relying on URL matching, and now that I'm giving it more thought, that does seem kind of unnecessarily flimsy.
And it doesn't stop a developer from having two browser windows open with a different partner running in each one. You just have to fire up separate servers for each environment variable (on different port numbers).
Although it is a little less slick than just being able to symlink and open http://schreyer.dev/ ...
I might like to make this even stricter and easier to handle change:
IOW, always require the environment variable to be present (and, perhaps, we should validate this value against a known list of good configurations?). I'm not sure what we should do if the variable isn't present, or if it's an unknown value. We could arbitrarily decide that one partner is the default, but that sets off alarm bells for me. Better to fail fast and communicate to the dev that something pretty fundamental is awry, methinks?
We'll want to have excellent documentation (and tooling) for adding partners, so that it's totally clear how to add a partner without missing any steps. Perhaps that tooling could include an entry into a list of known working configurations (to be initially populated with 'graduate' and 'schreyer').