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?