presenter registration DSL?

[nonnenmacher]

In #1023, you mentioned this as was raised again, some edge between grape-entity vs grape-roar and their implied rules (e.g on object representer deduction, implied rules of otpions hash transmitted to the actual presenter code...).

I am in the case, where I just candidely did a bundle update for a server in production for months, and grab new version of grape, multijson, representable, roar and what was perfectly working do not work anymore (some edge cases, no big deal, but in any way I look at it, this is kind of regression).

I'm using a small layer on top of roar, that is roughly the equivalent of what grape-roar, do in term of injecting the env hash down to representable lambdas inside representers.

Each time, I ask myself why I didn't choose grape-entity as premises from grape to the selection of representer class for an response object are make more closely, but I could not choose to drop roar as some constructs are pleasing (some promises of handling jsonapi... are nice).

It seems that your suggestion on #1023 (correlated I guess to #956) about a common Representer DSL, would be a great improvement to make the representation concern more predictable among various implementation.

For example, grape-entity and roar have different way of handling options hash entries (and remove then from the actual representer code (e.g for dealing with implicit field/exposure inclusion/exclusion, dropping the as: or with: for choosing a specific representer etc..

A DSL for that would bring a common ground for serving similar need for this cross-cutting concern of executing code of a designated representer/formatter for a given response object.

Moreover, as I spend hours looking at both roar, grape-entity it seems to me, that it would be beneficial to have the DSL isolate the fact, that such representer building/compiling could be done at that stage, and then reused on each object represented by the actual pre-build/assembled representer given a nice boost in term of request speed.

(note this subject is not very documented on roar and grape-entity and seems advanced so that both creators, certainly could find common ground just in term of documenting this kind of usages).

I know this is a lot, but the kind of DSL you outlined in #1023, seems I guess very likely to ressemble 90% of the existing code base eg. using :as or :with as alias of the same meaning to choose a proper representer class, will not break to much code, if we list what existing users have come to, in term of API flexibility by passing optional parameters from the :params hash to their own code (providing they avoided all the :as, :include[s], :exclude.. that the chosen libraries just consumed in the down flow, to their own code.

[dblock]

The representer DSL evolved "organically", so here we are. I would support the proposal above.

[nonnenmacher]

perhaps one way to gather current usage, will be for people to post here, the kind of presentation call they use to do and relate what could be generic to params from the API (like google way of filtering fields on response) and what is used to choose the proper representer class instance (best singleton producer of such representation, that could be recycled from one call to another).

I'm in the middle of adapting, my adapter to try using either roar or grape-entity (as a way to choose if I could migrate to grape-entity for some APIs and keep legacy one with roar or choose from endpoint to endpoint.