active_helper
Finally - helpers with proper encapsulation, delegation, interfaces and inheritance!
h1. ActiveHelper
Finally - helpers with proper encapsulation, delegation, interfaces and inheritance!
h2. Introduction
Helpers suck. They've always sucked, and they will suck on if we keep them in modules.
ActiveHelper is an attempt to pack helpers into classes. This brings us a few benefits
- inheritance helpers can be derived other helpers
-
delegation helpers are no longer mixed into a target- the targets @import@ the helper, where the new
methods are delegated to the helper instances - proper encapsulation helpers don't rely blindly on instance variables - a helper defines its @needs@, the target has to provide readers
- interfaces a helper clearly @provides@ methods and might @import@ additional helpers
Note that ActiveHelper is a generic helper framework. Not coupled to anything like Rails or Merb. Not providing any concrete helpers. Feel free to use clean helpers in any framework (including Rails and friends)!
h2. Installation
h2. Example
Let's use the bloody MVC-View example as we find in Rails or Merb (Sinatra, too?).
We have a view which needs additional methods in order to render bullshit.
h3. Using helpers
The view wants to render tags using the TagHelper.
To pull-in a helper we invoke @import@ on the target instance.
h3. Interfaces
The exemplary #tag method took me days to implement.
The helper defines a part of its interface (what goes out) as it @provides@ methods.
h3. Inheritance
The real power of OOP is inheritance, so why should we throw away that in favor of modules?
That's a bit cleaner than blindly including 30 helper modules in another helper in another helper, isn't it?
Obviously the view can invoke stuff from the FormHelper itself and inherited methods that were exposed with @provides@.
h3. Delegation as Multiple Inheritance
What if the #form_tag method needs to access another helper? In Rails, this would simply be
The #url_for methods comes from, na, do you know it? Me neither! It's mixed-in somewhere in the depths of the helper modules.
In ActiveHelper this is slightly different.
Hmm, our FormHelper is already derived from ActiveHelper, how do we import additional methods?
Easy as well, the helper class @uses@ it.
So we have to know #url_for is located in the UrlHelper and we even have to define which helpers it @uses@. That's a good thing for a) code tidiness, b) good architecture and c) debugging.
How would the UrlHelper look like?
h3. Delegation as Interface
A traditional url helper would roughly look like this:
Next chance, who or what did create @https_request? and where does it live? That's ugly, boys!
Our helper bets on declaring its interface, again! This time we define what goes in (a "dependency").
It defines what it @needs@ and that's all for it. Any call to #https_request? (that's a method) is strictly delegated back to the view instance, which has to care about satisfying dependencies.
Here's what happens in productive mode.
That's conclusive, the view is insufficiently geared.
Now, does it work?
Yeah.
h2. Rails Bindings
Use ActiveHelper in your Rails app! Assuming you'd be writing a helper for text munging, you would
- Write your helper and put it in @app/active_helpers/text_munging_helper.rb@.
- Prepare your controller.
- Use the imported methods in your views, just as you know it from other helpers.
h2. Concepts
- Helpers are instances, when accessing a raw @@ivar@ it refers to their own instance variables
- Dependencies between different helpers and between the target (e.g. a View instance) are modelled with OOP strategies: Inheritance and the declarative @#needs@.
h2. License
Copyright (c) 2010, Nick Sutterer
Released under the MIT License.