Sinatra w praktyce

Wcześniej, bo jakiś rok temu przedstawiłem jak w Sinatrze napisać najprostrzą aplikację. Ten sposób jest dobry, by szybko zademonstrować możliwości frameworka lub szybko przygotować zarys działającej aplikacji. Przy rozwijaniu aplikacji, lepiej jest nieco bardziej się postarać i całość ubrać w ładną klasę dziedzicząca po Sinatra::Base. Dzięki temu definicje odwołań nie będą znajdować się w głównej przestrzeni nazw.

#sinatraweb.rb
class HelloApplication < Sinatra::Base
  get '/' do
 "Hello World!"
  end
end

Poza efektem estetycznym aplikacja będzie mogła być łatwo rozszerzana lub też być
częścią jakiejś większej aplikacji, bez ryzyka, że dojdzie do konfliktów itp.

Dodatkowo aplikację należy wyposażyć w plik konfiguracyjny, przy pomocy którego
aplikacja będzie uruchamiana. Tak zwany plik "rackup" najczęściej w projektach
występujący pod nazwą config.ru

#config.ru
require 'rubygems'
require 'sinatra/base'
require 'sinatraweb.rb'

HelloApplication.run!

Zastosowanie tego pliku jest dosyć istotne gdy uruchamiamy aplikację na Heroku
lub na innych systemach wykorzystujących bibliotekę Rack. Przy pomocy pliku *.ru można ustawić parametry uruchomienia aplikacji takie jak port, adres tryb i działania.

Obsługa błędów 404 i innych

Zdarza się to dosyć często, że użytkownik nie trafia na stronę na którą sie spodziewał trafić. I tu pojawia się znany błąd 404. Sinatra domyślnie obsługuje tego typu błąd wywołując odpowiednie zdarzenie. Bez problemu możemy to zdarzenie nadpisać, aby wyświetlić własny widok.

Dwa proste przykłady

not_found do
 'Tu niczego nie ma!';
end

not_found do
 erb :error404 # dodajemy plik error404.erb do katalogu "views" 
end

Wszystkie inne błędy przechwycić można przez zdarzenie error:

error do
 "Kłopoty! " + request.env['sinatra.error'].message
end

Przełączanie środowiska

Normalnie Sinatra działa w trybie deweloperskim, jest to dosyć wolny tryb, część plików jest za każdym odwołaniem wczytywana ponownie. Przełączenie w tryb produkcyjny eliminuje ten problem. Dodatkowo pozwala to na skonfigurowanie oddzielnych środowisk do tworzenia, testowania i normalnego uruchamiania.
Ustawienie odpowiedniego środowiska polega na uruchomieniu metody set:

set :environment, :production # włączamy środowisko produkcyjne

W przypadku tworzenia aplikacji w osobnej klasie warto metodę tą dodać właśnie w definicji klasy aplikacji. Łatwe przełączanie między środowiskami pozwoli na używanie innych baz danych w środowisku deweloperskim i produkcyjnym, co wydaję się rozsądnym rozwiązaniem.

configure do
  # konfiguracja wspólna dla wszystkich trybów
end

configure :production do
  # konfiguracja środowiska produkcyjnego
end

configure :development do
  # środowisko deweloperskie
end

configure :test do
  # środowisko testowe
  # podpinamy np. inną bazę danych niż w środowisku deweloperskim
end

Więcej przydatnych wskazówek: http://sinatra-book.gittr.com