[RFC] Infer serializer from api namespace.

[drn]

@nhinze - I tested this against your project and it will solve your issue. You can try it out with the following:

gem 'grape-active_model_serializers', github: 'ruby-grape/grape-active_model_serializers', branch: 'namespace-inferred-serializer'

@dblock, @jrhe, @siong1987 - This change makes it so that the serializer lookup logic attempts to use the api namespace as the namespace of the serializer for both collection and resource inputs. This is a quick pass at the logic and not ready to be merged in. There are a number of items that I think still need to happen:

• Add specs for this
• Lookup namespace using both API class name and resource instead of just API class name
  • This solves @nhinze's use case, but wont work for others. It should use only namespace and resolve the serializer name based on the resource class
• Work with ASM maintainers to add the namespace option back into serializer lookup so we don't have to duplicate serializer lookup logic in grape-ASM
  • Because ASM doesn't accept that option anymore, grape-ASM doesn't have a hook for namespacing serializers without managing all of the lookup logic
• Figure out how grape-ASM should actually handle serializer resolution
  • Through options[:version]? Downsides are nested namespaces don't work well.
  • Through api namespace?

Without this pull, grape-ASM tries to resolve the serializer namespace using options[:version] and it only works for non-collection inputs. Otherwise, it just uses ASM's serializer lookup logic. I think using the namespace of the requesting api as the namespace of the serializer is probably the best bet and have ASM add support back for the namespace option and ensure it passes it through from collection serializers to the member serializers. Thoughts?

I'll be traveling until Thursday, but will get back to this after I return

[dblock]

Nice work, let us know when this is ready to merge.

[drn]

Cool, I'm traveling until Thursday but I'll update this after then. I'm planning on refactor the logic here pretty significantly if that's cool

[dblock]

Now that #59 is merged, this needs a rebase, thanks.

[dblock]

This is superseded by #60 and can be closed, right?

[drn]

Yup! Closing