h1. The Russion Doll Pattern

Yehuda Katz
Carl Lerche

Engines 3.0

h2. Community sharing

The same features are coming up over and over again

h2. Tired of making login pages?

Signup, login, forgot password
Why do we continue to repeat ourselves?

h2. Isn't a calendar just a calendar?

Wake up people!
Why don't we take that to a higher level?

h2. Several apps, One group

We need a good way to take the pieces we create at companies, and reuse them across applications

h2. Productivity vs. flexibility

C = High flexibility, low productivity
Engines = Low flexibility, high productivity

h2. Django

Entire pages - very limited flexibility
Acceptable tradeoff for many Django developers

Bunch of people has built frameworks on top of Django
Parts of pages, widgets

Django is evidence that this is doable


h2. Le's build an app

The code is completely made up, no alpha exists

rails forumz --namespaced # It should be just like coding a normal Rails app

config.app_namespace = "Forumz"

From that point, you should't have to specify the Forumz namespace again

script/generate resource Post

module Forumz
  class PostsController
    ...
  end
end

module Forumz
  class post
    ...
  end
end

h2. Cross-App URL generation

The router is being pushed out from Rails to the Rack-level.

class Application < ActionDispatch::App
  layout "application"

  routes do
    mount.warden "/accounts", :to => Warden
  
    mount.blog "/posts" do
      run Mephisto::App, :auth => warden
    end
  end
end

h3. In the app

blog.post_url(@post) => /awesome_blog/posts/123

h2. Another example

routes do
  mount.inbox "/inbox", :to => PMBox
  mount.blog "/posts" do
    ...
  end
end

The ultimate goal is to have other framework that handles various aspects for you


h2. Overriding

Specify your own templates in your actual app which override the ones in the engines


h2. Template customization

Engines must be easy to customize.
Engine Templates are an API

h3. Write more helpers

You have to be prudent about your choices for helpers
You shouldn't expect the user to override the entire template, so use helpers that can be overridden

h3. Use semantic HTML + CSS

Try harder to be less pragmatic and more semantic when building your HTML
csszengarden is a good example

h3. Parts

class SidebarPath < ActionController::Part
  def show
    @popular 
    ...
  end
end

h2. Migrations

Each application needs to maintain its own seperate tables
If you use down-migrations in production, that is crazy


Drupal does it, Wordpress does it, Django does it - why shouldn't we be able to do it?
Let's take Rails beyond a framework, let's make it a platform
It's not for everyone

You need to treat your engines like an API