On Sun, Dec 13, 2009 at 4:40 PM, Yehuda Katz wyc...@gmail.com wrote:
Long-term, we want to try to get away from using global state like
this as much as possible, but fixing it can sometimes open a thorny
can of worms. Koz's solution, paired with a mutex or thread-local (for
threadsafe
How about this approach (suggested by Adam Milligan):
class ActiveResource::Base
def self.connect(current_site)
old_site = site
begin
self.site = current_site
connection(:refresh)
yield
ensure
self.site = old_site
end
end
end
This would also need
Questions:
* Is there a reason it can't/shouldn't be an instance variable?
What would the api look like here? I could see something like
Seems I didn't hit paste...
ActiveResource::Base.with_site(...) do
ShopifyAPI::Shop.find(:first)
# etc.
end
--
Cheers
Koz
--
You received this
Long-term, we want to try to get away from using global state like
this as much as possible, but fixing it can sometimes open a thorny
can of worms. Koz's solution, paired with a mutex or thread-local (for
threadsafe scenarios) is a good workaround for now.
Sent from my iPhone
On Dec 13, 2009,
On Sun, Dec 13, 2009 at 4:40 PM, Yehuda Katz wyc...@gmail.com wrote:
Long-term, we want to try to get away from using global state like
this as much as possible, but fixing it can sometimes open a thorny
can of worms. Koz's solution, paired with a mutex or thread-local (for
threadsafe
This causes problems in the following scenario:
1. You use ActiveResource to post data to an external site using
subdomains for individual accounts (e.g. Lighthouse)
2. You want your app to allow multiple users to do this (register
their Lighthouse account/URI to automatically push their data
On Sun, Dec 13, 2009 at 7:19 PM, Chad Woolley thewoolley...@gmail.com wrote:
This causes problems in the following scenario:
1. You use ActiveResource to post data to an external site using
subdomains for individual accounts (e.g. Lighthouse)
2. You want your app to allow multiple users to do
