Project

base

0.14
No commit activity in last 3 years
No release in over 3 years
There's a lot of open issues
People love Base classes! They have tons of methods waiting to be used. Just check out `ActiveRecord::Base`'s method list: >> ActiveRecord::Base.methods.length => 530 But why stop there? Why not have even more methods? In fact, let's put *every method* on one Base class! So I did. It's called Base. Just subclass it and feel free to directly reference any class method, instance method, or constant defined on any module or class in the system. Like this: class Cantaloupe < Base def embiggen encode64(deflate(SEPARATOR)) end end >> Cantaloupe.new.embiggen => "eJzTBwAAMAAw\n" See that `embiggen` method calling `encode64` and `deflate` methods? Those come from the `Base64` and `Zlib` modules. And the `SEPARATOR` constant is defined in `File`. Base don't care where it's defined! Base calls what it wants! By the way, remember those 530 ActiveRecord methods? That's amateur stuff. Check out Base loaded inside a Rails app: >> Base.new.methods.count => 6947 It's so badass that it takes *five seconds* just to answer that question! Base is just craaazzy! It's the most fearless class in all of Ruby. Base doesn't afraid of anything!
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 2.12
>= 2.1.0
 Project Readme

Raptor Build Status Dependency Status

https://github.com/garybernhardt/raptor

DESCRIPTION

Raptor is an experimental web framework that encourages simple, decoupled objects. There are no base classes and as little "DSL" as possible. Raptor is not MVC; at least, not in the way that frameworks like Rails are. An example would be handy right about now:

module MyApp
  App = Raptor::App.new(self) do
    path "article" do
      show
      index
      update :if => :admin, :redirect => :index
    end
  end

  module Records
    class Article < YourFavoriteORM::Record
      # Do as you please
    end
  end

  module Constraints
    class Admin
      def match?(params)
        Records::User.find_by_id(params[:user_id]).admin?
      end
    end
  end

  module Presenters
    class Article
      def initialize(subject); @subject = subject; end
      def slug; @subject.title.to_slug; end
    end
  end
end

The first thing you notice: that's a lot of modules! Yes it is. You can break them into files in whatever way you want, but Raptor does expect this layout once everything is loaded.

The second thing you notice: there's no controller! Yes; this is because controllers are the devil. Instead, Raptor has an extremely powerful router:

Routes

Routes can:

  • delegate requests to objects you create.
  • enforce constraints (like "user must be an admin" in the example above).
  • redirect on success, or on certain exceptions, or both.
  • render views.
  • apply presenters before rendering.

The update route in the above example uses the default update behavior we know and love: the same stuff you've written in a hundred Rails controller actions. This behavior is the default in Raptor, but is completely overridable. Here we've overridden it to redirect to index instead of show, and to only work for admins. The request lifecycle is:

  1. Match PUT "/article/:id".
  2. Enforce the :admin constraint, defined by us in MyApp::Constraints::Admin. If the user isn't an admin, stop. The route doesn't match, even though the verb and path do.
  3. Call MyApp::Records::Article.find_and_update. It takes id and params. Raptor's dependency injector notices this, extracts the ID from the URL, as well as the params from the request, and passes them in.
  4. Redirect to /article, the index path. By default it would've gone to the show path, but we overrode it.

In addition, if find_and_update raised Raptor::ValidationError, it would've redirected to :edit. If a template had been rendered, it would've gone through MyApp::Presenters::Article. The full expansion of the update route is:

route :update, "PUT", "article/:id",
  :to => "MyApp::Records::Article.find_and_update",
  :redirect => :show, ValidationError => :edit`

All of the standard Raptor routes are syntactic sugar for these longer forms.

Application structure

By default, the router delegates to records. Records are not to contain application logic; delegation directly to records is only acceptable for very simple operations. For anything complex, it's your job to create relevant objects and point the router at them. Raptor provides you niceties related to the web: routing, presentation, template rendering, etc., but the core of your application—the logic—should have its own design that Raptor can't know ahead of time.

Raptor currently has no database layer. The records themselves are your job. As long as they have methods that match Raptor's interface, you'll be fine.

Rack apps and serving

An application is just a Ruby script:

#!/usr/bin/env ruby
require 'article'
App = Raptor::App.new(MyApp)

App is now a Rack app, so you can create a standard config.ru:

require './app'
run App

and run the app with rackup:

$ rackup

There's no autoloader and no discovery of your code: you explicitly require your source, give your app module to Raptor, and get a Rack app back.

Complex behavior and the injector

Any method that Raptor calls will be injected: subjects, presenters, requirements, even other injectables. Injection is purely name-based: if you have a method named request, it will get the Rack request as an argument. It's your job not to ask for HTTP data in deep layers of your application, like records (unless you really want to, in which case you can, but you should at least feel guilty about it).

Injection is how form parameters are handled, for example. If your route delegates to PostCreator.create(params), Raptor will automatically inject the request params as an argument. You can do the stuff you'd do in a Rails controller without hard coupling yourself to an ActionController::Base class. The reduced coupling makes testing easy and allows reuse (anyone who needs to create a post can use PostCreator!)

To define your own injectables , just define a class:

class MyApp::Injectables::Fruit
  def sources(injector)
    {:watermelon => lambda { "tasty" } }
  end
end

Now, if Raptor calls one of your methods that takes a watermelon argument, it will be passed "tasty".

LICENSE

Released under the MIT license: