

Renee, the friendly rack-based framework - joshbuddy
http://reneerb.com/

======
swah
Its amazing how propaganda from one genocidal regime is accepted, even cool,
but the other would get you banned anywhere.

~~~
dextorious
Who said it was a "genocidal regime"?

Americans who can't even point Russia on a map and know their history from the
History channel and New York Times bestseller books (if that)?

For hundreds of millions of people all around the world it was an inspiration,
even if faulty, and hardly comparable to nazism.

So, there.

~~~
tptacek
The Stalinist Soviet Union that website evokes was in fact a genocidal regime.
I don't know what specifically you're talking about; maybe it's some other
government.

It would probably be better not to hash this out on HN, though, so I've
downmodded the root comment on this thread.

------
robomc
Anyone got a 'why not Sinatra' for this?

~~~
joshbuddy
Essentially, it let's you take something like

    
    
      before '/blog/:id' do
        @blog = Blog.get(params[:id])
      end
      
      get '/blog/:id' do
        @blog
      end
      
      put '/blog/:id' do
        @blog.update_attributes(params)
      end
    

and turn it into

    
    
      path 'blog' do
        var do |id|
          @blog = Blog.get(id)
          get { halt @blog }
          put { @blog.update(request.params); halt :ok}
        end
      end
    

I feel this is DRY'er than the Sinatra representation. It also has nice
integration with Rack itself. The implementation is very simple, easy to get
into.

~~~
lobster_johnson
What I discovered recently when doing a new Rails 3 app was that the RESTful
CRUD stuff is all boilerplate. This is true about Sinatra apps, too: Every
GET, POST, PUT and DELETE are just wrappers around find, create update and
destroy. I used Rabl for generating JSON, so it was possible to write a single
serialization for all objects. So why not just boil everything down to the
minimal code required?

Something like this:

    
    
        handle '/blog'
    

That's it. This makes some assumptions:

* That /blog maps to a class Blog which it can load and save. * That you either use "fat models" (with callbacks that munge data and perform actions when data changes) or external observers (like ActiveRecord's observers). * That the model supports all four CRUD actions.

When you want additional verbs:

    
    
        handle 'GET /blog/search' do
          MySearchEngine.search(params[:q])
        end
    

Or object-specific ones:

    
    
        handle 'GET /blog/:id/search' do |blog|
          MySearchEngine.search(params[:q], :blog_id => blog.id)
        end
    

In fact, aside from extra verbs, you could get away with no code at all, since
you could introspect the database layer to discover which classes are
mappable.

My app is a JavaScript-based single-page HTML5 web application using Backbone,
so there is almost no server-side frontend code, meaning my app is basically a
server-side database anyway.

~~~
nakajima
I wrote something like this a while back:
<https://github.com/nakajima/sinatras-hat> It's no longer maintained, but it
was fun to see how many assumptions I could jam into one framework.

~~~
lobster_johnson
That's pretty cool!

------
mhd
Hmm, another Ruby web framework that goes the DSL route. Is there anything
available that generally tries to be a bit more explicit? Strangely enough,
camping seems to be the only somewhat well-known and maintained contender
here, and that has those global object and twee details…

~~~
petercooper
It's really easy to put together systems like this in Ruby now thanks to Rack.
What sort of API would you be interested in seeing?

~~~
mhd
Honestly, that's mostly why I'm asking. You're right, getting something to
work with Rack isn't hard. But getting a proper API in the first place, is.

~~~
petercooper
I totally agree. That's why I was interested to see if you had any ideas. I
find this sort of thing interesting and while I've played with ideas in the
past, I always come back to the standard patterns :)

------
pablodh
It's somewhat similar to this other microframework:
<https://github.com/soveran/cuba>

Not because of the name ;)

------
keen
Cool project.

Anyone know what inspired the name, theme etc?

~~~
joshbuddy
I have no idea how we got down the Russian path. Sort of started as a joke and
somehow went from there.

Renee is my gf's name, and she's very patient with me when I wanna work on
open source, so, it's a nod to her.

The inspiration for it came from Railsconf 2009 when one of the Sinatra guys
said how get "/:id" do |id| was a smell because of the id repeat. I had been
working on a new routing DSL for Goliath, when I got an itch to start making
simple, useful rack apps.

~~~
acangiano
Josh, I have not looked into the details of your framework, but why not
simplify the DSL to:

    
    
        path 'blog' do |id|
          @blog = Blog.get(id)
          get { halt @blog }
          put { @blog.update(request.params); halt :ok}
        end
    

Why do you need the var call within the block? Also, you seem to break the
ruby convention of using do end for blocks larger than one line, in many of
your examples.

(Again, I spent three seconds on your site, so you may have a solid reason for
this and have explained it already as well.)

~~~
nesquena
Yeah this is an early release. I can think of several ways to enhance the DSL
even more with ideas similar to this to cleanup common cases.

~~~
joshbuddy
Yeah, exactly. I wanna get a better handle on what these common cases are, so,
comments like this are wonderful.

------
carbon8
What's with the use of curly brackets for multi-line blocks?

~~~
rue
Most “rules” about {…} vs. do…end are nonsense. I tend to use {…} unless I
can't be bothered to put parens around the arguments.

~~~
ryeguy
They're nonsense in that they are without ryhme or reason, but you should be
following the community standard (curlies for one liners, do/end for
everything else).

I'd honestly pass on an open source project not following the generally agreed
upon ruby standard.

~~~
seanp2k2
>"They're nonsense in that they are without ryhme or reason, but you should be
following the community standard (curlies for one liners, do/end for
everything else)."

That's my reasoning too. At first, I thought it was more readable (read:
familiar) to use curly braces, but now I stick with do...end for blocks >1
line. Sometimes it's helpful for breaking up complex nested map() blocks as
well.

