{{{
A number of users (hundreds, maybe thousands) have been asking why representers are called representers and not “representations”. It is a valid question and since I spent decades to come up with this term I’d like to discuss the decision here quickly.
h3. What Is A Representation?
A representation in the REST style – and this is what we’re talking about here – is *a document describing a resource*. Actually, it is illustrating the current state of that resource, usually with property/value lists, embedded resources and pointers to other resources using hypermedia. The format is not relevant in this context, it could be JSON, HTML or the accursed XML.
It is a document you can pull on your hard disk, save it and pop it out on christmas again. Did I mention that I’m writing this post in a cafe facing the beach with a cold Castle in my hand, blinded by the sun and intrigued to jump back into the waves?
h3. What Is A Representer?
Now, on the other side, we have the representers as introduced by the roar gem. Those guys are Ruby code and out in the wild you might find them written as modules, mostly. A representer may look like the following beautiful snippet.
module FruitRepresenter
include Roar::Representer::JSON
property :title
link :self do
fruit_url(self)
end
end
In short, injected into an object that very instance gets capable of *rendering a document* from its current state _and_ updating its attributes by *parsing a document* – following the syntax definition from the representer module.
h3. Isn’t That A Presenter?
Ok. A representer module enhances an object by enriching it with new methods. Isn’t that a presenter, that’s “what Jason wants to know”:http://nicksda.apotomo.de/2011/12/ruby-on-rest-2-representers-and-the-dci-pattern/#comment-5255.
The idea seems interesting, but I’m confused as to how this is different from a traditional presenter or decorator?
What I learnt “from the tech panel _OOP vs. Rails_”:http://www.youtube.com/watch?v=jk8FEssfc90 at the fantastic Wroclove.rb conference – if I listened to Steve Klabnik correctly – is
- *Decorator* is a pattern that adds methods and optional state to an object. If I write a module introducing currency conversion methods into a float object it’s a Decorator.
- *Presenter* seems to be a subset of Decorator which adds functionality for, well, _presenting_ the object. That could be an ActiveRecord row instance extended with methods to serialize to JSON.
Steve, is that true?
So why is a representer not a presenter? Well, the answer is: *it is a presenter, but it is more*. The rendering behaviour as found in e.g. @to_json@ in the representer is clearly presentation logic. However, the parsing mechanics are definitely beyond the scope of a Presenter. I agree that a representer still is a Decorator (adding functionality, great).
h3. Why Isn’t It Called Representation?
People are worried about the “ter” ending (as in Terminater). Scott got justified concerns that choosing “representer” as opposed to “representation” has roots in my Ruby hipster attitude.
So, if “Representer” is a reflection of the popularity of “Presenter”,it would seem to be an example of throwing good money after bad. If “Presenter” is already somewhat tainted with inaccuracy, then so would “Representer”.
In an email he is refering to that confusion caused by the Presenter pattern name in the Ruby community (just google _presenter + ruby_ if you can’t follow now). So his proposal
The Fruit class is a “Representation”, not a representer.
Oh no, call it representation!
And as if that wasn’t enough critics on _MY_ pattern name, Charles Lowell, author of rubyracer, saviour of the poor and knight of the dark, reinforces the “representation argument”:https://github.com/apotonick/roar-rails/issues/10.
personally I prefer @FooRepresentation@ as opposed to @FooRepresenter@, but that’s just me. It implies that “this defines what the representation *is*”, as opposed to “This defines is how the representation is generated”
That sounds conclusive to me and lead me to reflecting the terms once again.
h3. Now What, Representer or Representation?
So, maybe the the concrete representation declaration (the module _using_ roar and defining properties and hyperlinks) is a representation whereas the underlying abstracted module is a representer?
I speaking for myself still prefer the name representer as we not only define syntax and semantic of a representational document but also add functionality to the represented object as it gets enriched with e.g. @to_json@ and @from_json@. *That as-it makes the @FruitRepresenter@ module “active”* and justifies the “ter” ending, just as in “Terminater”, ok?
}}}
Nick Sutterer 
I’d say you send :to_json to the representer (or just presenter) to get a JSON representation (or just presentation).
LikeLike
If the naming convention using “er” were applied as a general rule, you could say that an “Order” might be an “Orderer”, and a “Product” might be a “Producter”. What would happen with “Customer” then is another story 🙂
Whatever module/class in the underlying framework that has the implementation of to_json is likely the representer itself, whereas as module/class that leverages the framework is more attuned to being a representation.
As for presenters and decorators, those specific interpretations of the patterns are really quite particular to the rails ecosystem (arguably an insular and sometimes cut off ecosystem). The Rails versions of these patterns are either misunderstandings of the patterns at large, or misrepresentations, or both. This is a thing that I find really frustrating about Rails culture. It often spends insufficient time understanding the prior art before staking claim to an understanding. But that’s another issue altogether, and arguably one of opinion.
Decorator was communicated in the GoF book. Presenter was defined in an article by Martin Fowler, and has since been retired. It takes significant influence from Michael Feathers’ Humble Dialog Box.
In the end, the thing doing the work (the “er”) is in the guts of the framework. The thing using the framework is likely not the “er”. Although, Ruby’s mixins make this less clear because we can focus on the module design as a static model or focus on it as the dynamic model at runtime (where the module is mixed in, and the extended object essentially “becomes” the mixin. Naming usually benefits from sticking closer to the static model – but there are exceptions.
Fun issue to navigate, eh? 🙂
LikeLike
I like representer because it describes an action, it *does* something, like produce a representation of the object which is then static and just *is* — in this case the representer module is not static, it *does* something. So it makes total sense to me.
AFAIK, there is no “Ordtion” that matches “Order” — okay, there is a “Production” that kinda matches “Producer” but not sure one can carry the -er v. -tion to it’s full, whimsical conclusion.
And I guess you could say it re-presents the object, so it does what a presenter does but re-presents it in a way that delivers more? Just rambling now.
LikeLike