cells 4.0.0.beta6 → 4.0.0.rc1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: a5c2400e9d14760d1546557317bc9e98f97bb3b7
-  data.tar.gz: 4d7de6cd09957c5c12b7bd8b7030ebb119d5c5d5
+  metadata.gz: 6c08042fbea7ac33f3607605e1e290c0956b4312
+  data.tar.gz: 017db4d48f5a0eaab84f4ecb8fc014b9470f21f0
 SHA512:
-  metadata.gz: 2cc1c784ecb8a5e5838650b1e31beac41a03c92d5df45205b7811342d6acaba8a5a4dabeabf8eb752bfa0480fa784bda88a914e08ee14de9ce0ba7d7d7d8d123
-  data.tar.gz: a9c00ab7bcb2ab01132202756e1227cf50a6a976e3de7d69e9d9c74960874b7e910403cec640b12b63665e641acb850e0be3382a2d641d986f11b7b47e2dbef3
+  metadata.gz: 841380b7a18d52879c7f0323816cf78bec726d520478c55a52d8366fc9706974440572e96a1fa6298daa4a056c22f720a359c1e637a2df2c6547f40c3c34c021
+  data.tar.gz: da654a5b2dceec48cab59f4b89f3c40a9e2b326bc92d0040d1ccbcac0361ec91b7756501fd21dfdb612484b1453fde248925772cf3771eed61bc26ec083441d3

data/CHANGES.md

@@ -18,6 +18,10 @@
 
 * When using HAML, we do not use any of HAML's helper hacks to "fix" ActionView and XSS. While you might not note this, it removes tons of code from our stack.
 
+## 4.0.0.rc1
+
+* Move delegations of `#url_options` etc. to the railtie, which makes it work.
+
 ## 4.0.0.beta6
 
 * Removed `ViewModel::template_engine`. This is now done explicitly by including `Cell::Erb`, etc. and happens automatically in a Rails environment.

data/README.md

@@ -1,64 +1,87 @@
 # Cells
 
-*View Components for Rails.*
-
+*View Components for Ruby and Rails.*
 
 ## Overview
 
-Cells allow you to encapsulate parts of your page into separate MVC components. These components are called _view models_.
+Cells allow you to encapsulate parts of your UI into components into _view models_. View models, or cells, are simple ruby classes that can render templates.
 
-You can render view models anywhere in your code. Mostly, cells are used in views to replace a helper/partial/filter mess, as a mailer renderer substitute or they get hooked to routes to completely bypass `ActionController`.
+Nevertheless, a cell gives you more than just a template renderer. They allow proper OOP, polymorphic builders, nesting, view inheritance, using Rails helpers, [asset packaging](http://trailblazerb.org/gems/cells/rails.html#asset-pipeline) to bundle JS, CSS or images, simple distribution via gems or Rails engines, encapsulated testing, [caching](#caching), and [integrate with Trailblazer](#concept-cells).
 
-As you have already noticed we use _cell_ and _view model_ interchangeably here.
+## This is not Cells 3.x!
 
+Temporary note: This is the README and API for Cells 4. Many things have improved. If you want to upgrade, [follow this guide](https://github.com/apotonick/cells/wiki/From-Cells-3-to-Cells-4---Upgrading-Guide). When in trouble, join us on the IRC (Freenode) #trailblazer channel.
 
-## The Book
 
-Cells is part of the [Trailblazer project](https://github.com/apotonick/trailblazer). Please [buy my book](https://leanpub.com/trailblazer) to support the development and to learn all the cool stuff about Cells. The book discusses the following.
+## Rendering Cells
 
-<a href="https://leanpub.com/trailblazer">
-![](https://raw.githubusercontent.com/apotonick/trailblazer/master/doc/trb.jpg)
-</a>
+You can render cells anywhere and as many as you want, in views, controllers, composites, mailers, etc.
 
-* Basic view models, replacing helpers, and how to structure your view into cell components (chapter 2 and 4).
-* Advanced Cells API (chapter 4 and 6).
-* Testing Cells (chapter 4 and 6).
-* Cells Pagination with AJAX (chapter 6).
-* View Caching and Expiring (chapter 7).
+Rendering a cell in Rails ironically happens via a helper.
 
-More chapters are coming.
+```ruby
+<%= cell(:comment, @comment) %>
+```
 
-The book picks up where the README leaves off. Go grab a copy and support us - it talks about object- and view design and covers all aspects of the API.
+This boils down to the following invocation, that can be used to render cells in *any other Ruby* environment.
 
-## No ActionView
+```ruby
+CommentCell.(@comment).()
+```
 
-Starting with Cells 4.0 we no longer use `ActionView` as a template engine. Removing this jurassic dependency cuts down Cells' rendering code to less than 50 lines and improves rendering speed by 300%!
+In Rails you have the same helper API for views and controllers.
 
-**Note for Cells 3.x:** This README only documents Cells 4.0. Please [read the old README if you're using Cells 3.x](https://github.com/apotonick/cells/tree/31f6ed82b87b3f92613698442fae6fd61cc16de9#cells).
+```ruby
+class DasboardController < ApplicationController
+  def dashboard
+    @comments = cell(:comment, Comment.recent).()
+    @traffic  = cell(:report, TrafficReport.find(1))
+  end
+```
 
+Usually, you'd pass in one or more objects you want the cell to present. That can be an ActiveRecord model, a ROM instance or any kind of PORO you fancy.
 
-## Installation
+## Cell Class
 
-Cells run with all Rails >= 3.2. Lower versions of Rails will still run with Cells, but you will get in trouble with the helpers.
+A cell is a light-weight class with one or multiple methods that render views.
 
 ```ruby
-gem 'cells', "~> 4.0.0"
+class Comment::Cell < Cell::ViewModel
+  property :body
+  property :author
+
+  def show
+    render
+  end
+
+private
+  def author_link
+    link_to "#{author.email}", author
+  end
+end
 ```
 
-## Prerequisites
+Here, `show` is the only public method. By calling `render` it will invoke rendering for the `show` view.
 
-Cells comes bundled with ERB support. To render HAML, you have to include the [cells-haml](https://github.com/trailblazer/cells-haml) gem. The same for [cells-slim](https://github.com/trailblazer/cells-slim). Currently, they are only available as github dependencies, they will be released soon (early 2015).
 
-```ruby
-gem "cells-haml", github: 'trailblazer/cells-haml'
+## Logicless Views
+
+Views come packaged with the cell and can be ERB, Haml, or Slim.
+
+```erb
+<h3>New Comment</h3>
+  <%= body %>
+
+By <%= author_link %>
 ```
 
-The template engine extensions fix severe bugs in combination with Rails helpers and the respective engine. Time will tell if we can convince the template teams to merge these fixes.
+The concept of "helpers" that get strangely copied from modules to the view does not exist in Cells anymore.
 
+Methods called in the view are directly called _on the cell instance_. You're free to use loops and deciders in views, even instance variables are allowed, but Cells tries to push you gently towards method invocations to access data in the view.
 
-## File Layout
+## File Structure
 
-Cells are placed in `app/cells`.
+In Rails, cells are placed in `app/cells` or `app/concepts/`. Every cell has their own directory where it keeps views, assets and code.
 
 ```
 app
@@ -69,100 +92,321 @@ app
 │   │   ├── list.haml
 ```
 
+The discussed `show` view would reside in `app/cells/comment/show.haml`. However, you can set [any set of view paths](#view-paths) you want.
 
-## Generate
 
-Use the bundled generator to set up a cell.
+## Invocation Styles
 
-```shell
-rails generate cell comment
+In order to make a cell render, you have to call the rendering methods. While you could call the method directly, the prefered way is the _call style_.
+
+```ruby
+cell(:comment, @song).()       # calls CommentCell#show.
+cell(:comment, @song).(:index) # calls CommentCell#index.
 ```
 
+The call style respects caching.
+
+Keep in mind that `cell(..)` really gives you the cell object. In case you want to reuse the cell, need setup logic, etc. that's completely up to you.
+
+## Parameters
+
+You can pass in as many parameters as you need. Per convention, this is a hash.
+
+```ruby
+cell(:comment, @song, volume: 99, genre: "Jazz Fusion")
 ```
-create  app/cells/
-create  app/cells/comment
-create  app/cells/comment_cell.rb
-create  app/cells/comment/show.erb
+
+Options can be accessed via the `@options` instance variable.
+
+Naturally, you may also pass arbitrary options into the call itself. Those will be simple method arguments.
+
+```ruby
+cell(:comment, @song).(:show, volume: 99)
 ```
 
+Then, the `show` method signature changes to `def show(options)`.
+
 
-## Rendering View Models
+## Testing
 
-Suppose we are to render a "partial" for `Comment` model
+A huge benefit from "all this encapsulation" is that you can easily write tests for your components. The API does not change and everything is exactly as it would be in production.
 
 ```ruby
-@comment = Comment.find(1)
+html = CommentCell.(@comment).()
+Capybara.string(html).must_have_css "h3"
 ```
 
-Cells brings you one helper method `#cell` to be used in your controller views or layouts.
+It is completely up to you how you test, whether it's RSpec, MiniTest or whatever. All the cell does is return HTML.
 
-```haml
-= cell(:comment, @comment)
+[In Rails, there's support](http://trailblazerb.org/gems/cells/testing.html) for TestUnit, MiniTest and RSpec available, along with Capybara integration.
+
+## Installation
+
+Cells run with all Rails >= 4.0. Lower versions of Rails will still run with Cells, but you will get in trouble with the helpers.
+
+```ruby
+gem 'cells', "~> 4.0.0"
 ```
 
-This is the short form of rendering a cell. Simple, isn't it?
+(Note: we use Cells in production with Rails 3.2 and Haml and it works great.)
 
-Note that a view model _always_ requires a model in the constructor (or a composition). This doesn't have to be an `ActiveRecord` object but can be any type of Ruby object you want to present.
+Various template engines are supported but need to be added to your Gemfile.
 
-To understand invoking cells, here's the long form of it.
+* [cells-erb](https://github.com/trailblazer/cells-erb)
+* [cells-haml](https://github.com/trailblazer/cells-haml)
+* [cells-slim](https://github.com/trailblazer/cells-slim)
 
-```haml
-= cell(:comment, @comment).call(:show)
+```ruby
+gem "cells-erb"
+```
+
+In Rails, this is all you need to do. In other environments, you need to include the respective module into your cells.
+
+```ruby
+class CommentCell < Cell::ViewModel
+  include ::Cell::Erb # or Cell::Haml, or Cell::Slim
+end
+```
+
+## Concept Cells
+
+To have real self-contained cells you should use the new _concept cell_ which follows the [Trailblazer](http://trailblazerb.org) naming style. Concept cells need to be derived from `Cell::Concept`, sit in a namespace and are usually named `Cell`.
+
+```ruby
+class Comment::Cell < Cell::Concept
+  # ..
+end
+```
+
+Their directory structure looks as follows.
+
+```
+app
+├── concepts
+│   ├── comment
+│   │   ├── cell.rb
+│   │   ├── views
+│   │   │   ├── show.haml
+```
+
+This integrates with Trailblazer where classes for one _concept_ sit in the same directory. Please [read the book](http://leanpub.com/trailblazer) to learn how to use cells with Trailblazer.
+
+Concept cells are rendered using the `concept` helper.
+
+```erb
+<%= concept("comment/cell", @comment) %>
+```
+
+Other than that, normal cells and concept cells are identical.
+
+## Namespaces
+
+Cells can be namespaced as well. This is used for [concept cells](#concept-cells), too.
+
+```ruby
+module Admin
+  class CommentCell < Cell::ViewModel
 ```
 
-1. `#cell(..)` simply returns the cell instance. You can do whatever you want with it.
-2. `.call(:show)` will invoke the `#show` method respecting caching settings.
+Invocation in Rails would happen as follows.
+
+```ruby
+cell("admin/comment", @comment).()
+```
 
-When rendering cells in views, you can skip the `call` part as this is implicitely done by the template.
+Views will be searched in `app/cells/admin/comment` per default.
 
-Please [refer to the docs](#invocation-styles) for different ways of invoking view models.
 
+## Rails Helper API
 
-## View Model Classes
+Even in a non-Rails environment, Cells provides the Rails view API and allows using all Rails helpers.
 
-A view model is always implemented as a class. This gives you encapsulation, proper inheritance and namespacing out-of-the-box.
+You have to include all helper modules into your cell class. You can then use `link_to`, `simple_form_for` or whatever you feel like.
 
 ```ruby
 class CommentCell < Cell::ViewModel
-  def show
-    render
+  include ActionView::Helpers::UrlHelper
+  include ActionView::Helpers::CaptureHelper
+
+  def author_link
+    content_tag :div, link_to(author.name, author)
   end
+```
+
+As always, you can use helpers in cells and in views.
+
+You might run into problems with wrong escaping or missing URL helpers. This is not Cells' fault but Rails suboptimal way of implementing and interfacing their helpers. Please open the actionview gem helper code and try figuring out the problem yourself before bombarding us with issues because helper `xyz` doesn't work.
+
+
+## View Paths
+
+In Rails, the view path is automatically set to `app/cells/` or `app/concepts/`. You can append or set view paths by using `::view_paths`. Of course, this works in any Ruby environment.
+
+```ruby
+class CommentCell < Cell::ViewModel
+  self.view_paths = "lib/views"
 end
 ```
 
-Calling `#render` will render the cell's `show.haml` template, located in `app/cells/comment`. Invoking `render` is explicit: this means, it really returns the rendered view string, allowing you to modify the HTML afterwards.
+## Asset Packaging
+
+Cells can easily ship with their own JavaScript, CSS and more and be part of Rails' asset pipeline. Bundling assets into a cell allows you to implement super encapsulated widgets that are stand-alone. Asset pipeline is [documented here](http://trailblazerb.org/gems/cells/rails.html#asset-pipeline).
+
+## Render API
+
+## Nested Cells
+
+Cells love to render. You can render as many views as you need in a cell state or view.
+
+```ruby
+<%= render :index %>
+```
+
+The `#render` method really just returns the rendered template string, allowing you all kind of modification.
 
 ```ruby
 def show
-  "<div>" + render + "</div>"
+  render + render(:additional)
 end
 ```
 
-## Views In Theory
+You can even render other cells _within_ a cell using the exact same API.
 
-In Cells, we don't distinguish between _view_ or _partial_. Every view you render is a partial, every partial a view. You can render views inside views, compose complex UI blocks with multiple templates and go crazy. This is what cells _views_ are made for.
+```ruby
+def about
+  cell(:profile, model.author).()
+end
+```
 
-Cells supports all template engines that are supported by the excellent [tilt](https://github.com/rtomayko/tilt) gem - namely, this is ERB, HAML, Slim, and many more.
+This works both in cell views and on the instance, in states.
 
-In these examples, we're using HAML.
 
-BTW, Cells doesn't include the format into the view name. 99% of all cells render HTML anyway, so we prefer short names like `show.haml`.
+## Collections
+
+In order to render collections, Cells comes with a shortcut.
 
+```ruby
+comments = Comment.all #=> three comments.
+cell(:comment, collection: comments)
+```
 
-## Views In Practice
+This will invoke `cell(:comment, song).()` three times and concatenate the rendered output automatically. In case you don't want `show` but another state rendered, use `:method`.
 
-Let's check out the `show.haml` view to see how they work.
+```ruby
+cell(:comment, collection: comments, method: :list)
+```
 
-```haml
--# app/cells/comment/show.haml
+Note that you _don't_ need to invoke call here, the `:collection` behavior internally handles that for you.
 
-%h1 Comment
+Additional options are passed to every cell constructor.
 
-= model.body
-By
-= link_to model.author.name, model.author
+```ruby
+cell(:comment, collection: comments, style: "awesome", volume: "loud")
 ```
 
+## Caching
+
+For every cell class you can define caching per state. Without any configuration the cell will run and render the state once. In following invocations, the cached fragment is returned.
+
+```ruby
+class CommentCell < Cell::ViewModel
+  cache :show
+
+  # ..
+end
+```
+
+The `::cache` method will forward options to the caching engine.
+
+```ruby
+cache :show, expires_in: 10.minutes
+```
+
+You can also compute your own cache key, use dynamic keys, cache tags, and so on.
+
+```ruby
+cache :show { |model, options| "comment/#{model.id}/#{model.updated_at}" }
+cache :show, :if => lambda { |*| has_changed? }
+cache :show, :tags: lambda { |model, options| "comment-#{model.id}" }
+```
+
+Caching is documented [here](http://trailblazerb.org/gems/cells/caching.html) and in chapter 8 of the [Trailblazer book](http://leanpub.com/trailblazer).
+
+
+---------------------------------------
+
+ This is available via the `model` method. Declarative `::property`s give you readers to the model.
+
+
+Cells allow you to encapsulate parts of your page into separate MVC components. These components are called _view models_.
+
+You can render view models anywhere in your code. Mostly, cells are used in views to replace a helper/partial/filter mess, as a mailer renderer substitute or they get hooked to routes to completely bypass `ActionController`.
+
+As you have already noticed we use _cell_ and _view model_ interchangeably here.
+
+
+## The Book
+
+Cells is part of the [Trailblazer project](https://github.com/apotonick/trailblazer). Please [buy my book](https://leanpub.com/trailblazer) to support the development and to learn all the cool stuff about Cells. The book discusses the following.
+
+<a href="https://leanpub.com/trailblazer">
+![](https://raw.githubusercontent.com/apotonick/trailblazer/master/doc/trb.jpg)
+</a>
+
+* Basic view models, replacing helpers, and how to structure your view into cell components (chapter 2 and 4).
+* Advanced Cells API (chapter 4 and 6).
+* Testing Cells (chapter 4 and 6).
+* Cells Pagination with AJAX (chapter 6).
+* View Caching and Expiring (chapter 7).
+
+More chapters are coming.
+
+The book picks up where the README leaves off. Go grab a copy and support us - it talks about object- and view design and covers all aspects of the API.
+
+## No ActionView
+
+Starting with Cells 4.0 we no longer use `ActionView` as a template engine. Removing this jurassic dependency cuts down Cells' rendering code to less than 50 lines and improves rendering speed by 300%!
+
+**Note for Cells 3.x:** This README only documents Cells 4.0. Please [read the old README if you're using Cells 3.x](https://github.com/apotonick/cells/tree/31f6ed82b87b3f92613698442fae6fd61cc16de9#cells).
+
+
+## Installation
+
+Cells run with all Rails >= 3.2. Lower versions of Rails will still run with Cells, but you will get in trouble with the helpers.
+
+```ruby
+gem 'cells', "~> 4.0.0"
+```
+
+## Prerequisites
+
+Cells comes bundled with ERB support. To render HAML, you have to include the [cells-haml](https://github.com/trailblazer/cells-haml) gem. The same for [cells-slim](https://github.com/trailblazer/cells-slim). Currently, they are only available as github dependencies, they will be released soon (early 2015).
+
+```ruby
+gem "cells-haml", github: 'trailblazer/cells-haml'
+```
+
+The template engine extensions fix severe bugs in combination with Rails helpers and the respective engine. Time will tell if we can convince the template teams to merge these fixes.
+
+
+
+## Generate
+
+Use the bundled generator to set up a cell.
+
+```shell
+rails generate cell comment
+```
+
+```
+create  app/cells/
+create  app/cells/comment
+create  app/cells/comment_cell.rb
+create  app/cells/comment/show.erb
+```
+
+
+
 Cells provides you the view _model_ via the `#model` method. Here, this returns the `Comment` instance passed into the constructor.
 
 Of course, this view is a mess and needs be get cleaned up!
@@ -243,67 +487,9 @@ template_engine
 view_paths
 
 
-## Invocation styles
-
-The explicit, long form allows you rendering cells in views, in controllers, mailers, etc.
-
-```ruby
-cell(:comment, @comment).call(:show)
-```
-
-As `:show` is the default action, you don't have to specify it.
-
-```ruby
-cell(:comment, @comment).call
-```
 
-In views, the template engine will automatically call `cell.to_s`. It does that for every object passed in as a placeholder. `ViewModel#to_s` exists and is aliased to `#call`, which allows to omit that part in a view.
 
-```haml
-= cell(:comment, @comment)
-```
 
-If you want, you can also call public methods directly on your cell. Note that this does _not_ respect caching, though.
-
-```haml
-= cell(:comment, @comment).avatar
-```
-
-## Passing Options
-
-There's several ways to inject additional state into your cell.
-
-### Object Style
-
-Cells can receive any set of options you need. Usually, a hash containing additional options is passed as the last argument.
-
-```ruby
-cell(:comment, @comment, layout: :fancy)
-```
-
-The third argument is accessable via `#options` in the instance.
-
-```ruby
-def show
-  render layout: options[:layout]
-end
-```
-
-### Functional Style
-
-You can also pass options to the action method itself, making your cell a bit more functional with less state.
-
-```ruby
-cell(:comment, @comment).call(:show, layout: :fancy)
-```
-
-Make sure the method is ready to process those arguments.
-
-```ruby
-def show(layout=:default)
-  render layout: layout
-end
-```
 
 ## Collections
 
@@ -369,42 +555,6 @@ Multiple calls to `::builds` will be ORed. If no block returns a class, the orig
 
 
 
-# TODO: merge stuff below!
-
-## File Structure
-
-In Cells 3.10 we introduce a new _optional_ file structure integrating with [Trailblazer](https://github.com/apotonick/trailblazer)'s "concept-oriented" layout.
-
-This new file layout makes a cell fully **self-contained** so it can be moved around just by grabbing one single directory.
-
-Activate it with
-
-```ruby
-class Comment::Cell
-  self_contained!
-
-  # ...
-end
-```
-
-Now, the cell directory ideally looks like the following.
-
-```
-app
-├── cells
-│   ├── comment
-│   │   ├── cell.rb
-│   │   ├── views
-│   │   │   ├── show.haml
-│   │   │   ├── list.haml
-```
-
-
-Here, cell class and associated views are in the same self-contained `comment` directory.
-
-You can use the new views directory along with leaving your cell _class_ at `app/cells/comment_cell.rb`, if you fancy that.
-
-
 ## Asset Pipeline
 
 Cells can also package their own assets like JavaScript, CoffeeScript, Sass and stylesheets. When configured, those files go directly into Rails' asset pipeline. This is a great way to clean up your assets by pushing scripts and styles into the component they belong to. It makes it so much easier to find out which files are actually involved per "widget".
@@ -481,156 +631,7 @@ class Comment::FormCell < Cell::Rails
 When rendering views in `FormCell`, the view directories to look for templates will be inherited.
 
 
-## Caching
-
-Cells allow you to cache per state. It's simple: the rendered result of a state method is cached and expired as you configure it.
-
-To cache forever, don't configure anything
-
-```ruby
-class CartCell < Cell::Rails
-  cache :show
-
-  def show
-    render
-  end
-```
 
-This will run `#show` only once, after that the rendered view comes from the cache.
-
-
-### Cache Options
-
-Note that you can pass arbitrary options through to your cache store. Symbols are evaluated as instance methods, callable objects (e.g. lambdas) are evaluated in the cell instance context allowing you to call instance methods and access instance variables. All arguments passed to your state (e.g. via `render_cell`) are propagated to the block.
-
-```ruby
-cache :show, :expires_in => 10.minutes
-```
-
-If you need dynamic options evaluated at render-time, use a lambda.
-
-```ruby
-cache :show, :tags => lambda { |*args| tags }
-```
-
-If you don't like blocks, use instance methods instead.
-
-```ruby
-class CartCell < Cell::Rails
-  cache :show, :tags => :cache_tags
-
-  def cache_tags(*args)
-    # do your magic..
-  end
-```
-
-### Conditional Caching
-
-The +:if+ option lets you define a condition. If it doesn't return a true value, caching for that state is skipped.
-
-```ruby
-cache :show, :if => lambda { |*| has_changed? }
-```
-
-### Cache Keys
-
-You can expand the state's cache key by appending a versioner block to the `::cache` call. This way you can expire state caches yourself.
-
-```ruby
-class CartCell < Cell::Rails
-  cache :show do |options|
-    order.id
-  end
-```
-
-The versioner block is executed in the cell instance context, allowing you to access all stakeholder objects you need to compute a cache key. The return value is appended to the state key: `"cells/cart/show/1"`.
-
-As everywhere in Rails, you can also return an array.
-
-```ruby
-class CartCell < Cell::Rails
-  cache :show do |options|
-    [id, options[:items].md5]
-  end
-```
-
-Resulting in: `"cells/cart/show/1/0ecb1360644ce665a4ef"`.
-
-
-### Debugging Cache
-
-When caching is turned on, you might wanna see notifications. Just like a controller, Cells gives you the following notifications.
-
-* `write_fragment.action_controller` for cache miss.
-* `read_fragment.action_controller` for cache hits.
-
-To activate notifications, include the `Notifications` module in your cell.
-
-```ruby
-class Comment::Cell < Cell::Rails
-  include Cell::Caching::Notifications
-```
-
-### Inheritance
-
-Cache configuration is inherited to derived cells.
-
-
-
-### A Note On Fragment Caching
-
-Fragment caching is [not implemented in Cells per design](http://nicksda.apotomo.de/2011/02/rails-misapprehensions-caching-views-is-not-the-views-job/) - Cells tries to move caching to the class layer enforcing an object-oriented design rather than cluttering your views with caching blocks.
-
-If you need to cache a part of your view, implement that as another cell state.
-
-
-### Testing Caching
-
-If you want to test it in `development`, you need to put `config.action_controller.perform_caching = true` in `development.rb` to see the effect.
-
-
-## Testing
-
-Another big advantage compared to monolithic controller/helper/partial piles is the ability to test your cells isolated.
-
-### Test::Unit
-
-So what if you wanna test the cart cell? Use the generated `test/cells/cart_cell_test.rb` test.
-
-```ruby
-class CartCellTest < Cell::TestCase
-  test "show" do
-    invoke :show, :user => @user_fixture
-    assert_select "#cart", "You have 3 items in your shopping cart."
-  end
-```
-
-Don't forget to put `require 'cell/test_case'` in your project's `test/test_helper.rb` file.
-
-Then, run your tests with
-
-```shell
-rake test:cells
-```
-
-That's easy, clean and strongly improves your component-driven software quality. How'd you do that with partials?
-
-
-### RSpec
-
-If you prefer RSpec examples, use the [rspec-cells](http://github.com/apotonick/rspec-cells) gem for specing.
-
-```ruby
-it "should render the posts count" do
-  render_cell(:posts, :count).should have_selector("p", :content => "4 posts!")
-end
-```
-
-To run your specs we got a rake task, too!
-
-```shell
-rake spec:cells
-```
 
 
 ### Call
@@ -743,48 +744,7 @@ end
 
 This will simply render the `author.haml` template in the same context as the `show` view, meaning you might use helpers, again.
 
-### Encapsulation
 
-If in doubt, encapsulate nested parts of your view into a separate cell. You can use the `#cell` method in your cell to instantiate a nested cell.
-
-Designing view models to create kickass UIs for your domain layer is discussed in 50+ pages in [my upcoming book](http://nicksda.apotomo.de).
-
-### Alternative Instantiation
-
-You don't need to pass in a model, it can also be a hash for a composition.
-
-```ruby
-  cell(album, song: song, composer: album.composer)
-```
-
-This will create two readers in the cell for you automatically: `#song` and `#composer`.
-
-
-Note that we are still working on a declarative API for compositions. It will be similar to the one found in Reform, Disposable::Twin and Representable:
-
-```ruby
-  property :title, on: :song
-  property :last_name, on: :composer
-```
-
-
-## Mountable Cells
-
-Cells 3.8 got rid of the ActionController dependency. This essentially means you can mount Cells to routes or use them like a Rack middleware. All you need to do is derive from Cell::Base.
-
-```ruby
-class PostCell < Cell::Base
-  ...
-end
-```
-
-In your `routes.rb` file, mount the cell like a Rack app.
-
-```ruby
-match "/posts" => proc { |env|
-  [ 200, {}, [ Cell::Base.render_cell_for(:post, :show) ]]
-}
-```
 
 ### Cells in ActionMailer
 
@@ -815,21 +775,6 @@ module MyApp
 end
 ```
 
-### Base Path
-
-You can configure the cells path in case your cells don't reside in `app/cells`.
-
-```ruby
-config.generators do |g|
-  g.base_cell_path "app/widgets"
-end
-```
-
-
-## Capture Support
-
-If you need a global `#content_for` use the [cells-capture](https://github.com/apotonick/cells-capture) gem.
-
 
 ## Undocumented Features