Down with Helpers!
Up with Decorators!
Why helpers are great but decorators are even nicer!
David Worth - dave@highgroove.com

Helpers are great
They move business logic out of and views into a testable unit:
What's wrong with helpers?
Flat namespaces lead to collisions:
What's wrong with helpers? (con't)
I had no idea what the load order for helpers was.
What is the Decorator Pattern? (con't)
From the Wiki:
In object-oriented programming, the decorator pattern is a design pattern that allows behaviour to be added to an existing object dynamically.
Pretty much.
What is the Decorator Pattern? (con't)
But it gets better:
The decorator pattern can be used to extend (decorate) the functionality of a certain object at run-time, independently of other instances of the same class, provided some groundwork is done at design time.
What is the Decorator Pattern? (con't)
Neat! But how?
This is achieved by designing a new decorator class that wraps the original class.
Think proxy classes!
What is the Decorator Pattern? (con't)
There is a wealth of OO literature on the subject...
Introducing Draper!
Draper adds namespaces to helpers!
How does it work?
Proxy objects of AREL proxy objects
It slices
Draper handles associations gracefully too
It slices
Draper handles associations gracefully too
It dices
Decorators are a great place to put output formatters for things like XML, JSON, CSV that may need custom formatting.
Putting these presentation concerns in your model should feel funny...
It dices
It dices
Note the alternative decoration syntax above.
(This idea blatantly lifted from the docs)
It even enforces interfaces
References
- More Info
- Draper on Github
- Railscast #286 - Draper
- Experimenting with Draper from Jumpstart Lab
- Decorator Pattern on Wikipedia
/