garybernhardt / raptor Goto Github PK
View Code? Open in Web Editor NEWAn experimental web framework.
An experimental web framework.
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:
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.
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?
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.
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?
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?
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.
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.
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.
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).
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?
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.
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.
But should this go in the README?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.