1

I have an application that takes weather input from weather stations via a POST request. The problem is that the firmwares have a lot of quirks which I would like to move to separate "adapter" controllers which would normalise the parameters and forward the requests.

The quirks include stuff like using shortened float, attribute identifiers and urls to save memory/bandwith.

example:

POST /m -> ArdiunoController#create -> (normalize) -> ObservationController#create

Why? the "kosher" controllers will swell out of control if they have handle all the weirdness of different firmware. The models should not be concerned with input normalisation.

max
  • 96,212
  • 14
  • 104
  • 165
  • This is not a duplicate of: http://stackoverflow.com/questions/10592353/rails-how-to-post-internally-to-another-controller-action see *Why?* – max Sep 15 '14 at 21:36

1 Answers1

0

It looks like an issue of how you want to organize your code.

You don't have to limit yourself to ActiveRecord based Models, you can create your own model that handles data normalization.

class Normalizer
  def self.normalize_params(params)
    case params[:firmware_version]
    when 'ardiuno'
      # do stuff
    when 'something_else'
      # do something else
    end
    return params
  end
end

In your controller you can call it like this:

normalized_params = Normalizer.normalize_params(params)

That way your logic is tucked away and everything should work. No need to create separate controllers for each firmware, as long as the firmware version is in the params they can all go to the same controller.

Josh
  • 8,329
  • 4
  • 36
  • 33
  • Well, that would be nice except the firmware does not send version, I have to deduce it by the route or the format of the parameters. I would actually prefer using controller concerns in this case since I´m not entirely convinced that models should know about params. – max Sep 18 '14 at 15:24