Add controller lookup.

[beauby]

This PR adds the controller's namespace to the lookup chain, such that the following works:

class User < ActiveModel::Base
  ...
end

module Api
  module V1
    class UsersController < ApplicationController
      def index
        render json: User.all
      end
    end
    class UserSerializer < ActiveModel::Serializer
      ...
    end
  end
end

[NullVoxPopuli]

Nice!! I'm really looking forward to this. 'automatic' api versioning will be a huge help to a lot of people.

[NullVoxPopuli]

I think passing the controller name to serializer_for seems weird. Would just passing the namespace make more sense? so that way you don't need to deconstantize that later?

[NullVoxPopuli]

related: #886, #671, #562 (@beauby, I actually had a version of this going a long time ago, before that project gave up on the idea of having a versioned API), #539, #499, #381, #144, #108

[bf4]

So, is the controller being used as a serializer lookup hint? If so, I'd rather allow people to add 'hints' (I think this is was Grape calls them). I think passing the controller class all the way through AMS has pretty low value, since it adds a lot of noise for what could be resolved by specifying the class name.

I'd rather work on the JSON API unless there's a lot of pressure for something like this.

[beauby]

@bf4 Agreed, I made this PR because I knew how to do it without much effort, but it's not among the top priority stuff.
The one use-case I think this is really helpful is when handling two versions of a same API (say in Api::V1 and Api::V2) where the models do not change, but the serializers do.

[bf4]

Yeah, def something to figure out, maybe with a serializer version param or namespace param (which could be derived from controller or specufied)

[NullVoxPopuli]

@bf4 could you elaborate?

I really like @beauby's approach, as it allows for a mirrored file/folder structure of api versions between the 'serializers' and controllers

[bf4]

Yeah, as controllers mirror resource routes, i agree serializers should reflect those paths...

Let's look at how other libs do it

[NullVoxPopuli]

Do you know of other libs that do this?

I think other than how the namespace (re: not the namespace, but the controller class) is passed to the serializable resource, the implementation is pretty good.

[NullVoxPopuli]

needs rebase

[beauby]

@NullVoxPopuli I'll eventually rebase this if we end up deciding to include it. Currently, it is more meant as a proof of concept than anything else.

[NullVoxPopuli]

Well, my vote is for including it :-)

[beauby]

I wouldn't mind including it either, but I'd also like for one of @hut8's (I believe) @tchak's PRs that creates a context object, in which we could stick the controller class so that this feature needs less hacking.

[NullVoxPopuli]

fair enough :-)

[tchak]

I would prefer a way to pass in an api version... I feel like the lookup (serializer_for) should take the whole options hash, in order to make possible some advanced use cases.

[NullVoxPopuli]

there are many ways to handle api versioning.

Some people like to have it namespaced in their routes, others like to have the version specified in a header.

We may need to support both.

[bf4]

@beauby This PR should be superseded by #1289

[beauby]

@bf4 I don't think so, as you don't want to replace, say the current_user with current_controller_class or something. Instead, I think it would be nice to rebuild this PR on top of @tchak's PR introducing the serialization_context object.

[bf4]

@beauby yeah, I pasted the wrong link.. edited comment above to refer to #1289 (comment)

[bf4]

Should this PR still be open?

[elfassy]

Will this get merged? Or is there something else taking its place?

[beauby]

@elfassy This PR will probably not get merged, as it was meant as a proof of concept and much has changed in the meantime. I still think the feature would be useful, and would support a PR doing this in a clean way, or maybe issue one myself when I have a bit of free time.

[beauby]

Closing in favor of #1436.