= Components
This plugin attempts to implement components in the simplest, cleanest, fastest way possible. Inspired by the Cells plugin (http://cells.rubyforge.org) by Nick Sutterer and Peter Bex.
A component can be thought of as a very lightweight controller with supporting view templates. The difference between a component "controller" and a Rails controller is that the component controller's methods are very much normal methods - they accept arguments, and they return a string. There is no magical auto-rendering, and there is no access to data that is not a) in the arguments or b) in the database. For example, there is no access to the request, the request parameters, or the session. This is designed to encourage good design and reuse of components, and to ensure that they don't take over the request/response job of your Rails controllers.
Speaking imprecisely, components prepare for and then render templates.
== Usage
Note that these examples are very simplistic and would be better implemented using Rails partials.
=== Generator
Running `script/generator users details` will create a UsersComponent with a "details" view. You might then flesh out the templates like this:
class UsersComponent < Components::Base
def details(user_or_id)
@user = user_or_id.is_a?(User) ? user_or_id : User.find(user_or_id)
render
end
end
=== From ActionController
class UsersController < ApplicationController
def show
return :text => component("users/detail", params[:id])
end
end
=== From ActionView
<%= component "users/detail", @user %>
== More Features
=== Caching
Any component action may be cached using the fragment caching you've configured on ActionController::Base. The command to cache a component action must come after the definition of the action itself. This is because the caching method wraps the action, which makes the caching work even if you call the action directly.
Example:
class UsersComponent < Components::Base
def details(user_id)
@user = User.find(user_id)
render
end
cache :details, :expires_in => 15.minutes
end
This will cache the returns from UsersComponent#details using a cache key like "users/details/5", where 5 is the user_id. The cache will only be good for fifteen minutes. See Components::Caching for more information.
=== Helpers
All of the standard helper functionality exists for components. You may define a method on your component controller and use :helper_method to make it available in your views, or you may use :helper to add entire modules of extra methods to your views.
Be careful importing existing helpers, though, as some of them may try and break encapsulation by reading from the session, the request, or the params. You may need to rewrite these helpers so they accept the necessary information as arguments.
=== Inherited Views
Assume two components:
class ParentComponent < Components::Base
def one
render
end
def two
render
end
end
class ChildComponent < ParentComponent
def one
render
end
def three
render "one"
end
end
Both methods on the ChildComponent class would first try and render "/app/components/child/one.erb", and if that file did not exist, would render "/app/components/parent/one.erb".
=== Standard Argument Options
You may find yourself constantly needing to pass a standard set of options to each component. If so, you can define a method on your controller that returns a hash of standard options that will be merged with the component arguments and passed to every component.
Suppose a given component:
class GroupsComponent < Components::Base
def details(group_id, options = {})
@user = options[:user]
@group = Group.find(group_id)
render
end
end
Then the following setup:
class GroupsController < ApplicationController
def show
render :text => component("groups/details", params[:id])
end
protected
def standard_component_options
{:user => current_user}
end
end
Would expand to:
component("groups/details", params[:id], :user => current_user)
== Components Philosophy
I wrote this components plugin after evaluating a couple of existing ones, reflecting a bit, and either stealing or composing the following principles. I welcome all debate on the subject.
=== Components <em>should not</em> simply embed existing controller actions.
Re-using existing controller actions introduces intractable performance problems related to redundant controller filters and duplicate request-cached variables.
=== Components <em>should not</em> have the concept of a "request" or "current user".
Everything should be provided as an argument to the component - it should not have direct access to the session, the params, or any other aspect of the request. This means that components will never intelligently respond_to :html, :js, :xml, etc.
=== Components _should_ complement RESTful controller design.
The path of least resistance in Rails includes RESTful controller design to reduce code redundancy. Components should only be designed for use cases where RESTful controller design is either awkward or impossible. This compatibility will reduce the maintenance effort for components and help them grow with Rails itself.
Copyright (c) 2008 Lance Ivy, released under the MIT license
