garybernhardt / raptor Goto Github PK

I tried running the test suite, and I am getting a lot of failures. It works fine on 1.9.2 though. The failures seem to be related to includes in RSpec contexts, which are expected to pull in constants, but apparently don't on 1.9.3.

Here's a gist which illustrates the difference: https://gist.github.com/1354361

I have no idea why this is occuring. I will investigate further, just wanted to jot this down here.

Current application structure:

A Raptor application is composed of resources, which can contain routes, requirements, presenters, and records. The file layout matches the module hierarchy. E.g., the example application contains a "posts" file with classes like Posts::PresentsOne and Posts::Record. In a larger resource, these might be separate files like posts/presenters.rb and posts/record.rb, but that's the programmer's problem; Raptor doesn't know about files.

My concerns:

1. The number of things that can go in a resource. To the four above we'll add custom injection sources, and we've waffled back and forth on separating the record class into two: a record and a repository to hold queries. That would make six things that can go in a resource, and I'm sure we'll discover more.

2. The word "resource". A Raptor resource is not a resource in the REST sense, which bothers me. It's not self-contained and not necessarily exposed to the outside. I don't know what to name it without dropping back to something even more generic like "component", which makes me think that it's the wrong abstraction. Tom and I have struggled with this since we were first sitting in a coffee shop in Seattle thinking about Raptor with pen and paper.

Possible solution:

If resources are to be removed as a concept, the only option I see is a Rails-style separation: organize by type (presenter, etc.), then by name. Rails does this by file: app/models/post.rb, and its users often dump all of the resulting classes into the global namespace. If we did it, I'd want to do it by module scope, not file. You define YourAppName::Presenters::Post, regardless of how the source is laid out. Raptor will still guess at the names for defaults (as Rails does).

Problems:

Two things worry me about this change. First, it might turn apps into incomprehensible ravioli if the culture becomes "one class per file". Of course, this being Ruby, you could structure your files in the old way (posts.rb containing all post-related pieces). You'd just be reopening modules a lot. I'd really like to see how this works out.

Second, routes don't fit into this scheme as nicely as they do into resources. Currently, all routes are implicitly (and inescapably) prefixed with their resource name (e.g., "/posts/"). Decoupling the two means that you'll have to specify the prefixes somehow, and I fear descending into the hierarchical complexity of Rails routes (Raptor's routing is quite subtle as it is).

Do you share my fears about resource bigness? Do you share my fears about the module-based solution? Do you see another solution we've missed so far?

Tom, when you asked "Should raptor include asset serving itself?", are you asking about simply serving a public directory, or are you asking about fancy asset pipeline stuff like the changes in Rails 3 that I don't understand?

I read through the original discussion of this, and there were lots of good things there. I want to use DCI, and separate my application like Uncle Bob's "lost architecture" talk mentioned (which I've also seen before reading the previous discussion).

I've got an app that looks like this:

module MyApp
  App = Raptor::App.new(self) do
    root :render => "root", :present => :home_page
    path "user" do
      index :to => 'Repository::User.all'
      new
      create :to => 'MyApp::Context::CreateUser.execute', :redirect => :index
    end
  end
end

I've got a context that looks like this:

module MyApp
  module Context
    class CreateUser
      def self.execute(user, params)
        raise Raptor::ValidationError if params['email'].empty? || params['password'].empty?
        user.email = params['email']
        user.password = params['password']
        user.extend(UnregisteredUser).register
        {:user => @user}¬                        
      end

      protected

      module UnregisteredUser
        def register
          Arden::Repository.for(:user).create(self)
        end
      end
    end
  end
end

So questions:

• Is there a way to get validation errors into the presenter? I'm guessing I'd want to use some kind of DI injector for this, but I'm at a loss on how to write it. It didn't look like Raptor::ValidationError had any way of storing errors or anything like that.
• I'm also thinking that using Raptor::ValidationError directly inside my context class is a bad idea. Raptor is a delivery mechanism, so I should be making a buffer layer to handle the translation of my app and the delivery mechanism (raptor, in this case)
• All in all, I think it's a little murky how things get passed around in the system. A little more documentation would help here, I think, explaining specifically what the conventions should be (this seems to be a largely convention based system).

I think the big "how to design an app with raptor" question is how to properly pass data around the layers. DI seems like the preferred way, but it's unclear to me how to write an Injectables class that does this.

It would be cool if we didn't have to load Raptor in order to require a particular resource.

Currently we have this:

module Posts
  Routes = Raptor.routes(self) do
    ...
  end

if we change this to:

module Posts
  def self.routes
    Raptor.routes(self) do
      ...
    end
  end

it's a little more verbose, but we don't have to have Raptor defined in order to load this resource.

What do you think?

Sorry I am spamming the issue tracker with a lot of dumb stuff. Just had this realization.

When using a datastore that isn't an ORM/ODM, it doesn't really make sense to talk about records. Since Raptor wants to make no assumption as to how we're structuring our app, and it would make a lot of sense for the "Record" in a lot of cases not to map 1-1 to a database row/document, I think it should have a different name.

Resource is kind of already taken by raptors nomenclature, otherwise that would have been good, maybe Model is better? What do you think?

Following the example in /examples I couldn't make the update action work. Here's the form:

# edit.html.erb
<form method="POST" action="/posts/<%= id %>">
  <input type="hidden" name="_method" value="PUT" />
  Title: <input type="text" name="title" value="<%= title %>" />
  <input type="submit">
</form>

I managed to make this work by including the Rack::MethodOverride in config.ru file. I wonder how this could be handled by default in raptor.

But should this go in the README?

This looks pretty interesting, but seems to be abandoned. Will there be any more work on it or should I move on my merry way?

I was playing around with raptor recently and tried hooking it up to a Sequel backed.

Unfortunately I was unable to directly use sequel as a record because the sequel new and create methods expect a 'values' parameter to be passed (Instead of 'params'). In order to get it working I had to create an adapter to convert the incoming 'params' to 'values'.

Looking at the project readme it seems like Inferables might be the solution to this problem. Not sure if your still working on raptor but if you have any advice for implementing Inferables or another solution I'm happy to take a crack at it.

Sorry I am spamming the issue tracker with a lot of dumb stuff. Just had this realization.

When using a datastore that isn't an ORM/ODM, it doesn't really make sense to talk about records. Since Raptor wants to make no assumption as to how we're structuring our app, and it would make a lot of sense for the "Record" in a lot of cases not to map 1-1 to a database row/document, I think it should have a different name.

Resource is kind of already taken by raptors nomenclature, otherwise that would have been good, maybe Model is better? What do you think?