4 ms·

Anyone got a 'why not Sinatra' for this?

• deleted 15y ago
  [deleted]
• joshbuddy 15y ago
  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.
  • judofyr 15y ago
    Here's the same in Camping, using plain Ruby: class Blog < R '/blog/(\d+)' def service(id) @blog = Blog.get(id); super end def get(id) render :blog end def put(id) @blog.update_attributes(@input) end end
  • soveran 15y ago
    The same in Cuba (http://cuba.is http://cuba.is): Cuba.define do on "blog/:id" do |id| blog = Blog.get(id) on(get) { res.write blog } on(put) { blog.update(req.params); res.write :ok } end end
    • seanp2k2 15y ago
      These all seem like good ideas in their own way. I say "it's great that we have all these useful ways of doing similar things!". Choose whatever best fits your application. I really like that this type of stuff is catching on over Rails.
  • lobster_johnson 15y ago
    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 15y ago
      I wrote something like this a while back: https://github.com/nakajima/sinatras-hat 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 15y ago
        That's pretty cool!
• DanielRibeiro 15y ago
  Yes. But they say why: http://reneerb.com/concept http://reneerb.com/concept
  • robomc 15y ago
    Right, I guess that sort of rewriting of CRUD situations would be nice in some cases. Although in real applications, most of your methods are complex enough that you'd want them to be multiline blocks, at which point it would start to get really ugly IMO. Anyway it sounds like I'm being more critical than I actually am I think. But my un-DRY annoyance with Sinatra isn't writing multiple blocks with route declarations for CRUD methods, so much as not being able to refer to those routes in your views abstractly. ie., if you decide you want to change from /comments/:id to /awesome-comments/:id, it's a headache. I assume there are plugins to fix that annoyance, but I'd have like Sinatra to generally have routing more abstracted from specific URL paths.
    • nesquena 15y ago
      Yeah we agree regarding route generation being important. We came up with a decent solution to it for Renee, let us know what you think: http://reneerb.com/route-generation http://reneerb.com/route-generation and time will tell but we think the combination of clearer routes, leaner code and url generation makes renee a fun alternative.
    • joshbuddy 15y ago
      It's also easy to split a Renee application into multiple parts, but, I'd really like to address this more going forward, to make it easier.