Set default representer config

[gdlx]

Here is a callback method in ControllerAdditions allowing to send default url options to the representer config from the controller's requestobject.

This avoids having to set these options in environment config files when you want to use the current request host, port and protocol.

However, these options can still be overridden in environment config files as before (static config is merged over default one).

The set_representer_config method could be used to set other representer default configuration values from the controller (for now, only url options seems useful).

If you aggree with this feature, I can update the readme and/or specs.

[gdlx]

Now it should build on Rails 3.0 and 3.2.

[bglusman]

I beleive we have a case for it being dynamic in production.... our software is multi-tenant and run on multiple TLDs and subdomains, always using the current domain for API calls... I suppose it's possible we could move to a single domain for all API calls, but we're currently dealing with threading issues with a module that gets included in controlleer and called with around_filter

module RequestHost

def set_host_on_current_thread Thread.current[:amicus_current_host] = request.host Thread.current[:amicus_current_protocol] = request.protocol Thread.current[:amicus_current_port] = request.port.to_i yield Thread.current[:amicus_current_host] = nil Thread.current[:amicus_current_protocol] = nil Thread.current[:amicus_current_port] = nil end

end

[apotonick]

Hello friends, sorry for the delay. I looked into this.

I like @gauthier-delacroix' idea of allowing overriding default values by overriding a controller method. This logic shouldn't be in a dynamic block in an initializer (I mean, it could be, but that is the last resort). I can change roar-rails so it processes a hash when the representer is applied. My last comment illustrates this.

Doing this on a controller-base (with the option of an application-wide initializer block) would allow proper testing for that! You wouldn't have to change a global to test if the host computing kicks in, etc.