I'm currently developing a Sinatra/Rack app, and I've run into a design problem. I was looking around, and I'm not quite sure where to place the bulk of the require statements.
I figure they go in one of two places, either the main.rb after requiring Sinatra itself, or they go in the config.ru so they are all loaded at the start of the application.
I'm currently leaning towards the main.rb as that is what's loaded by all of the testing applications.
Thank you for your help.
I recommend:
Require your main app file only from your config.ru.
Require Sinatra and views gems in your main app
Create individual init.rb files for each of your helpers, models, and routes, and require those in your main app.
Require DB-related gems in models/init.rb
Here's an example of the layout I use:
Using Sinatra for larger projects via multiple files
Note that by loading DB-related gems and setting up your DB in your models/init.rb you can (from IRB) load just that file and have your full model stack available for poking at.
Take a look at this blog post by Engine Yard. It does a fairly good job of explaining what you want to know: https://www.engineyard.com/blog/using-the-rubygems-bundler-for-your-app
Take a look at my source code.
https://github.com/sirfilip/sinatrablog
:)
Just realized i have to remove all of the require statements in my models since they are not needed anyway.
The most interesting file in there is the bootloader.rb. If you want to follow the request path start from the config ru which acts as a front controller for the app.
Related
I am using Sinatra and erb on Passenger/Apache. Every time I made edit to the erb file, I have to restart Apache and refresh in the browser.
Is there any way to edit the file and sinatra can instantly update it? I mean simply by clicking the refresh button in the browser can one view the update?
Conclusion:
If you are in dev on sinatra, you can use shotgun or SinatraLoader.
If you are using Passenger, you can create an empty file: tmp\always_restart.txt
Yes, you can use Sinatra::Reloader.
Sinatra::Reloader
Extension to reload modified files. Useful during development, since it will automatically require files defining routes, filters, error handlers and inline templates, with every incoming request, but only if they have been updated.
You can use Shotgun for that: https://github.com/rtomayko/shotgun
Shotgun
This is an automatic reloading version of the rackup command that's shipped with
Rack. It can be used as an alternative to the complex reloading logic provided
by web frameworks or in environments that don't support application reloading.
I have an action with
def new
#test_var = 'i want this to show'
end
All I want to do is inject that into the javascript called for that page. For example:
#app/assets/javascript/my_model.js.coffee.erb
$ ->
console.log('<%= #test_var %>')
I'm guessing this doesn't work because that the coffeescript/erb is compiled before the controller is accessed...so, if I wanted to inject controller variables into a JavaScript file (client side - NOT accessed via ajax) in 3.1, how should I go about doing it?
I believe the problem is that you're thinking about the asset pipeline all wrong...
asset being the operative word.
It's not a view pipeline. Other things which are assets? images & css files, things which can be preprocessed and then served as-is. The erb/preprocessing of your assets doesn't occur on each pageload/request, rather it occurs on startup/filechange so in production said assets can be optimised, cached and served statically.
You could probably figure out a way to achieve it using Live Compilation (see section 4.2 of http://guides.rubyonrails.org/asset_pipeline.html) but as the docs say:
This mode uses more memory and is lower performance than the default. It is not recommended.
The bad answer would be 'inject the javascript into your view', but decoupling your javascript from your rails controllers/views is a good idea.
A better answer would be to have an asset folder containing all of your controller javascripts, and use some "what page am I on?" javascript to determine whether to run the code or not.
Here's some answers that explain various approaches to this:
Rails 3.1 asset pipeline: how to load controller-specific scripts?
Using Rails 3.1, where do you put your "page specific" javascript code?
I need an easy way to generate static web pages so that I can serve them up with Apache or Nginx. Currently I am using SproutCore's build tool (Abbot) to generate static pages but that is a little bit cumbersome as it is designed for building SproutCore apps, not non-SproutCore HTML pages.
Here are my requirements:
Javascript must be combined and minified
CSS files must be combined
Each image / CSS / Javascript asset must have unique URL for better caching (query string isn't enough)
Asset URL should be different only when it really changes
Localization support thorough HTML, CSS, Javascript and image files
Nice template engine with layouts, partials etc.
Here are possible solutions I have found:
Create the site using Ruby on Rails, then get all resources using wget like http://usefulfor.com/ruby/2009/03/23/use-rails-to-create-a-static-site-rake-and-subversion/
Use Middleman: http://middlemanapp.com
Any thoughts on this?
After a longish evaluation process I have decided to use Middleman. It does the trick and I love its simplicity and the fact that I can use existing Rack components with it.
Best Regards,
Pekka Mattila
I'm the creator of Middleman and would be eager to help you get comfortable using Middleman. My main goal is to give users the power of Rails, but focused on static development. Some of the actual code of Middleman is simplified versions of Ab
Here's what I do:
Ruby on Rails 3 with the High Voltage Gem, which makes it easy
to serve a static page body using the common templates. It requires a
simple entry in the routes (and you can use namespaces to create a
hierarchy).
Apache reverse proxy to stand-alone Passenger (which uses nginx I
believe) to run the Rails app. This article describes how to
configure it.
Stand-alone passenger will read the URL, see if there is a corresponding file in /public with the .html on it, and serve that. If not found, it will invoke Rails and generate the page. In essence, page caching, with the option of publishing your URLs with or without the .html. There is a section in the Passenger docs about page caching specifically.
As far as combining and minifying js and css, here's a good stackoverflow thread.
Rails has excellent i18n/l10n support.
Rails template engine is very nice to work with. And you can use HAML if you prefer.
For your 3rd and 4th points, I'm a little confused. You want css and js combined, but then you want each to have it's own URL. In Rails, the "cache => true" directive on asset tags takes care of adding a query string parameter that changes when the content does, which is a fairly traditional scheme. I'm not sure what context you are working in where that would not work. Any CDN I've ever used works fine with that, as does an web server implementing the HTTP spec correctly. Anyway, changing the actual path or file in the URL would require changing all references to it. Maybe I'm misunderstanding?
Monkeyman has the template engine you need, I think. Think of it as Middleman's little Scala brother. Nowhere as mature or feature rich yet, but we'll get there eventually. The current incarnation supports HAML, Jade, SSP for layouts, Markdown for content and a couple of other things.
Without any special order
jekyll - quite simple
middleman - a lot of funcionalities
nanoc - a lot of funcionalities
stasis - use controllers
staticmatic
frank
gumdrop
ruby on rails + wget
ruby on rails + high voltage + apache reverse proxy
You should probably also checkout mod_pagespeed. It will at least give you this:
Javascript must be combined and minified
CSS files must be combined
Each image / CSS / Javascript asset must have unique URL for better caching (query string isn't enough)
Asset URL should be different only when it really changes
It won't give you this:
Localization support thorough HTML, CSS, Javascript and image files
Nice template engine with layouts, partials etc.
You can have a look at docpad. It's written in coffeescript and runs on Nodejs. It is document based, where you write some documents and layouts, it will compile them and write them in the out directory. You can write documents in a lot of languages via plugins
It also supports multiple level of file compilation. For example from eco to markdown to html.
Another great feature of it is that you can query on other documents being generated in a document. For example in the first page, you have something like this to get all blog posts:
database.findAll({url : /posts/})
Which will return all documents having posts in their url.
I'm attempting to use Padrino's routing as a standalone addition to a basic Sinatra application.
http://www.padrinorb.com/guides/standalone-usage-in-sinatra
The main reason I need/want the additional Padrino functionality is the ability to separate my routes into multiple controller files.
Is this something I can do without using the whole Padrino package? If so, where do I place the separate controller files? I've tried /controllers/main.rb and /app/controllers/main.rb, where my core Sinatra app is at /app.rb.
You don't quite need to use the padrino routing to achieve the idea of controllers in Sinatra. In your main .rb file for your Sinatra app you can do:
Dir.glob("controllers/*.rb").each { |r| require_relative r }
Place your "controllers" into a controllers directory and the above will require_relative all of them for you. The code all gets lumped into the main ruby file eventually but you gain the ability to logically separate the code.
I would like to know how to provide a Ruby application with a REST API. I could code something based on Ruby's TCPServer API, but that seems a bit low-level. Do you think it would be a good solution? Or do you recommend a better approach?
You can use Sinatra to write tiny, focused web applications and lightweight REST services very quickly.
In the documentation section they highlight a couple of videos on that matter:
Adam Wiggins and Blake Mizerany present Sinatra and RestClient at RubyConf 2008. The talk details Sinatra’s underlying philosophy and reflects on using Sinatra to build real world applications.
Adam Keys and The Pragmatic Programmers have started a series of screencasts on Sinatra. The first two episodes cover creating a tiny web app and creating a REST service. $5 a pop.
You can also use rails as well, but that's a little overkill...
There are several layers involved when desiging a RESTful API, and at each layer there are several valid approaches.
TCPServer is indeed very low level, since you would have to implement the HTTP protocol yourself, which is not recommended.
One step up would be Rack, which takes care of all the low-level HTTP details. This is what all Ruby web frameworks like Rails, Sinatra or Ramaze use under the hood. It also assures that your application works on various application servers, like Passenger, Thin or Unicorn.
But even Rack is still low level, it gives you HTTP, but higher level frameworks take the boilerplate out of typical web programming. For an API you could look at a minimal framework like Sinatra, or a framework specifically designed for APIs like Grape or Rails::API. These will already assume a RESTful style API, so you should find them to be a natural fit.
Typical RESTful APIs are characterized by having resources identified by guessable (convention driven) URLs, and operations on those based on HTTP methods (verbs) like GET, POST, PUT, DELETE and PATCH. To truly embrace the spirit of REST as it was described by Roy Fielding however, you could move towards a more full "Hypermedia" API. The most visible difference is that responses are more self-contained. They are of well-defined media types (defined by yourself or by existing specs) containing links to related resources, rather than merely numerical ids. Similarly responses contain templates/forms describing the operations that can be performed. (There is more to it, but on the surface level that's what you will notice.)
This makes the API more discoverable, both by humans and machines, and it allows for a greater freedom in evolving the API. There could be a performance drawback, since a client typically would need to do more requests to achieve the same thing, but this can be prevented by well thought out design and caching. Garner is specifically made to provide easy server-side caching.
You could define your own media types that suit your application, commonly on top of JSON or XML, or you could look at existing specifications, notably Collection+JSON, HAL and JSON-API. It seems at the moment HAL has the biggest traction, with several libraries available on a variety of platforms.
There is seemingly not a whole lot happening around JSON-API, but two signifacnt projects, ActiveModel::Serializers and Ember-data, are both adopting (and at the same time, developing) this format, which means it could become a popular choice in the Ruby/Rails world.
Edit : typo
I'm using Sinatra too to develop simple REST solutions.
The thing is Sinatra is so flexible in many ways. You can build your project structure the way you like more. Usualy we have a lib/ tmp/ and public/ directories and a config.ru and app.rb files but as I sayd you can build whatever you want.
To remember is that Sinatra is not an usual MVC just because de M (model). For you to use sinatra for Simple CRUD web applications you need simply to load a gem.
require 'datamapper'
or other of your choice like sqlite, sequel, ActiveRecord, ...
and voilá you got a ORM under your Sinatra.
Under Sinatra you define routes that obey to four main proposes GET, PUT POST and DELETE.
require 'rubygems'
require 'sinatra'
get '/' do
erb :home
end
get '/API/*' do
api = params[:splat]
#command_test = api[0]
#command_helo = api[1]
#...
def do_things(with_it)
#...
end
#...
end
__END__
##home
helo
well you got the ideia :)
Finally. Learning Sinatra is not a waste of time because of it simplicity and because it gives (me) foundations of what web programming is.
I think In a near future it will be possible to "inject" Sinatra apps (Rack Apps) into a Rails3 project.
Take a look into github, there you will find many project built with Sinatra.
For further reading checkout Sinatra::Base.
For simple REST APIs I would also consider working directly against the Rack library (i.e. you may not need a framework like Sinatra). Routing for example can be quite easy for simple cases. I've put together a little example here: https://gist.github.com/4685445