2011-08-02 16:11:56 +00:00
|
|
|
= Sinatra
|
2011-11-24 08:49:37 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
<i>Attention : Ce document correspond à la traduction de la version anglaise et
|
2011-03-06 21:01:52 +00:00
|
|
|
il n'est peut être plus à jour.</i>
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Sinatra est un DSL pour créer rapidement et facilement des applications web en
|
|
|
|
Ruby :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
# mon_application.rb
|
|
|
|
require 'sinatra'
|
2011-07-05 17:08:58 +00:00
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
get '/' do
|
2011-05-02 12:44:49 +00:00
|
|
|
'Bonjour le monde !'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Installez la gem et lancez avec :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-09-21 06:57:26 +00:00
|
|
|
gem install sinatra
|
|
|
|
ruby -rubygems mon_application.rb
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Le résultat est visible sur : http://localhost:4567
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Il est recommandé d'exécuter également <tt>gem install thin</tt>, pour que
|
|
|
|
Sinatra utilise le server Thin quand il est disponible.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Routes
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Dans Sinatra, une route est une méthode HTTP couplée à un masque (pattern)
|
2011-07-05 17:08:58 +00:00
|
|
|
URL. Chaque route est associée à un bloc :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
.. montrer quelque chose ..
|
|
|
|
end
|
|
|
|
|
|
|
|
post '/' do
|
|
|
|
.. créer quelque chose ..
|
|
|
|
end
|
|
|
|
|
|
|
|
put '/' do
|
2011-04-05 21:20:17 +00:00
|
|
|
.. remplacer quelque chose ..
|
|
|
|
end
|
|
|
|
|
|
|
|
patch '/' do
|
2010-09-21 06:46:20 +00:00
|
|
|
.. changer quelque chose ..
|
|
|
|
end
|
|
|
|
|
|
|
|
delete '/' do
|
|
|
|
.. effacer quelque chose ..
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
options '/' do
|
|
|
|
.. apaiser quelquechose ..
|
|
|
|
end
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Les routes sont évaluées dans l'ordre où elles ont été définies. La première
|
|
|
|
route qui correspond à la requête est appelée.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Les masques peuvent inclure des paramètres nommés, accessibles par
|
2011-05-02 12:44:49 +00:00
|
|
|
l'intermédiaire du hash <tt>params</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/bonjour/:nom' do
|
|
|
|
# répond aux requêtes "GET /bonjour/foo" et "GET /bonjour/bar"
|
|
|
|
# params[:nom] est 'foo' ou 'bar'
|
2011-05-02 12:44:49 +00:00
|
|
|
"Bonjour #{params[:nom]} !"
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Vous pouvez aussi accéder aux paramètres nommés directement grâce aux
|
|
|
|
paramètres du bloc comme ceci :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/bonjour/:nom' do |n|
|
2011-05-02 12:44:49 +00:00
|
|
|
"Bonjour #{n} !"
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Une route peut contenir un splat (caractère joker), accessible par
|
2011-07-05 17:08:58 +00:00
|
|
|
l'intermédiaire du tableau <tt>params[:splat]</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/dire/*/a/*' do
|
2011-07-05 17:08:58 +00:00
|
|
|
# répond à /dire/bonjour/a/monde
|
2010-09-21 06:46:20 +00:00
|
|
|
params[:splat] # => ["bonjour", "monde"]
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/telecharger/*.*' do
|
2011-07-05 17:08:58 +00:00
|
|
|
# répond à /telecharger/chemin/vers/fichier.xml
|
2010-09-21 06:46:20 +00:00
|
|
|
params[:splat] # => ["chemin/vers/fichier", "xml"]
|
|
|
|
end
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Ou par l'intermédiaire des paramètres du bloc :
|
|
|
|
|
|
|
|
get '/telecharger/*.*' do |chemin, ext|
|
|
|
|
[chemin, ext] # => ["path/to/file", "xml"]
|
|
|
|
end
|
|
|
|
|
|
|
|
Une route peut aussi être définie par une Expression Régulière :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get %r{/bonjour/([\w]+)} do
|
2011-05-02 12:44:49 +00:00
|
|
|
"Bonjour, #{params[:captures].first} !"
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Là encore on peut utiliser les paramètres de bloc :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get %r{/bonjour/([\w]+)} do |c|
|
2011-05-02 12:44:49 +00:00
|
|
|
"Bonjour, #{c} !"
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-08-02 16:11:56 +00:00
|
|
|
Les routes peuvent aussi comporter des paramètres optionnels :
|
|
|
|
|
|
|
|
get '/posts.?:format?' do
|
|
|
|
# répond à "GET /posts" et aussi à "GET /posts.json", "GET /posts.xml" etc...
|
|
|
|
end
|
|
|
|
|
2012-03-03 09:46:20 +00:00
|
|
|
A ce propos, à moins d'avoir désactivé la protection contre les attaques par
|
|
|
|
"path transversal" (voir plus loin), l'URL demandée peut avoir été modifiée
|
|
|
|
avant d'être comparée à vos routes.
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Conditions
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Les routes peuvent définir toutes sortes de conditions, comme par exemple le
|
2011-05-02 12:44:49 +00:00
|
|
|
"user agent" :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
|
|
|
|
"Vous utilisez Songbird version #{params[:agent][0]}"
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
# Correspond à tous les autres navigateurs
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Les autres conditions disponibles sont +host_name+ et +provides+ :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
get '/', :host_name => /^admin\./ do
|
2011-05-02 12:44:49 +00:00
|
|
|
"Zone Administrateur, Accès refusé !"
|
2010-10-06 22:11:36 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
get '/', :provides => 'html' do
|
|
|
|
haml :index
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/', :provides => ['rss', 'atom', 'xml'] do
|
|
|
|
builder :feed
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Vous pouvez facilement définir vos propres conditions :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
set(:probability) { |value| condition { rand <= value } }
|
|
|
|
|
|
|
|
get '/gagner_une_voiture', :probability => 0.1 do
|
2011-05-02 12:44:49 +00:00
|
|
|
"Vous avez gagné !"
|
2010-10-06 22:11:36 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
get '/gagner_une_voiture' do
|
|
|
|
"Désolé, vous avez perdu."
|
|
|
|
end
|
|
|
|
|
2011-09-01 09:03:27 +00:00
|
|
|
Utilisez un splat (caractère joker) dans le cas d'une condition qui prend
|
|
|
|
plusieurs valeurs :
|
|
|
|
|
|
|
|
set(:auth) do |*roles| # <- ici on utilise un splat
|
|
|
|
condition do
|
|
|
|
unless logged_in? && roles.any? {|role| current_user.in_role? role }
|
2012-03-05 23:54:55 +00:00
|
|
|
redirect "/login/", 303
|
2011-09-01 09:03:27 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
get "/mon/compte/", :auth => [:user, :admin] do
|
|
|
|
"Informations sur votre compte"
|
|
|
|
end
|
|
|
|
|
2012-03-06 00:04:22 +00:00
|
|
|
get "/reserve/aux/admins/", :auth => :admin do
|
2011-09-01 09:03:27 +00:00
|
|
|
"Seuls les administrateurs sont acceptés ici !"
|
|
|
|
end
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Valeurs de retour
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
La valeur renvoyée par le bloc correspondant à une route constitue le corps de
|
|
|
|
la réponse qui sera transmise au client HTTP ou du moins au prochain middleware
|
|
|
|
dans la pile Rack. Le plus souvent, il s'agit d'une chaîne de caractères,
|
2011-03-06 21:01:52 +00:00
|
|
|
comme dans les exemples précédents. Cependant, d'autres valeurs sont
|
|
|
|
acceptées.
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Vous pouvez renvoyer n'importe quel objet qu'il s'agisse d'une réponse Rack
|
|
|
|
valide, d'un corps de réponse Rack ou d'un code statut HTTP :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
* Un tableau de 3 éléments : <tt>[code statut (Fixnum), entêtes (Hash), corps
|
|
|
|
de la réponse (répondant à #each)]</tt>
|
|
|
|
* Un tableau de 2 élements : <tt>[code statut (Fixnum), corps de la réponse
|
2011-03-06 21:01:52 +00:00
|
|
|
(répondant à #each)]</tt>
|
|
|
|
* Un objet qui répond à <tt>#each</tt> et qui ne transmet que des chaînes de
|
|
|
|
caractères au bloc fourni
|
2011-07-05 17:08:58 +00:00
|
|
|
* Un Fixnum représentant le code statut
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Avec cela, on peut facilement implémenter un streaming par exemple :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
class Stream
|
|
|
|
def each
|
|
|
|
100.times { |i| yield "#{i}\n" }
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
get('/') { Stream.new }
|
|
|
|
|
2011-09-01 15:32:10 +00:00
|
|
|
Vous pouvez aussi utiliser le helper +stream+ (présenté un peu plus loin) pour
|
|
|
|
éviter la surcharge et intégrer le traitement relatif au streaming dans le bloc
|
|
|
|
de code de la route.
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Masques de route spécifiques
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Comme cela a été vu auparavant, Sinatra offre la possibilité d'utiliser des
|
|
|
|
masques sous forme de chaines de caractères ou des expressions régulières
|
|
|
|
pour définir les routes. Mais il est possible de faire bien plus. Vous pouvez
|
2011-03-06 21:01:52 +00:00
|
|
|
facilement définir vos propres masques :
|
|
|
|
|
|
|
|
class MasqueToutSauf
|
|
|
|
Masque = Struct.new(:captures)
|
|
|
|
|
|
|
|
def initialize(except)
|
|
|
|
@except = except
|
2011-03-09 08:32:03 +00:00
|
|
|
@captures = Masque.new([])
|
2011-03-06 21:01:52 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def match(str)
|
|
|
|
@caputres unless @except === str
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def tout_sauf(masque)
|
|
|
|
MasqueToutSauf.new(masque)
|
|
|
|
end
|
|
|
|
|
|
|
|
get tout_sauf("/index") do
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
2011-07-05 17:08:58 +00:00
|
|
|
Notez que l'exemple ci-dessus est bien trop compliqué et que le même résultat
|
2011-03-06 21:01:52 +00:00
|
|
|
peut être obtenu avec :
|
|
|
|
|
|
|
|
get // do
|
|
|
|
pass if request.path_info == "/index"
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
|
|
|
Ou bien en utilisant la forme négative :
|
|
|
|
|
|
|
|
get %r{^(?!/index$)} do
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
== Fichiers statiques
|
|
|
|
|
2011-08-02 16:34:21 +00:00
|
|
|
Les fichiers du dossier <tt>./public</tt> sont servis de façon statique. Vous
|
|
|
|
avez la possibilité d'utiliser un autre répertoire en définissant le paramètre
|
2011-06-15 22:24:27 +00:00
|
|
|
<tt>:public_folder</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-06-15 22:24:27 +00:00
|
|
|
set :public_folder, File.dirname(__FILE__) + '/statique'
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-08-02 16:34:21 +00:00
|
|
|
Notez que le nom du dossier public n'apparait pas dans l'URL. Le fichier
|
2012-03-06 00:04:22 +00:00
|
|
|
<tt>./public/css/style.css</tt> sera appelé via l'URL :
|
2011-08-02 16:34:21 +00:00
|
|
|
<tt>http://exemple.com/css/style.css</tt>.
|
|
|
|
|
|
|
|
Utilisez le paramètre <tt>:static_cache_control</tt> pour ajouter l'information
|
|
|
|
d'en-tête <tt>Cache-Control</tt> (voir plus loin).
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
== Vues / Templates
|
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Chaqie langage de template est disponible via sa propre méthode de rendu,
|
|
|
|
lesquelles renvoient tout simplement une chaîne de caractères.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :index
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Ceci effectue le rendu de la vue <tt>views/index.erb</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Plutôt que d'utiliser le nom d'un template, vous pouvez directement passer
|
|
|
|
le contenu du template :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-03 21:27:51 +00:00
|
|
|
code = "<%= Time.now %>"
|
|
|
|
erb code
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Les méthodes de templates acceptent un second paramètre, un hash d'options :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :index, :layout => :post
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Ceci effectuera le rendu de la vue <tt>views/index.erb</tt> en l'intégrant
|
|
|
|
au +layout+ <tt>views/post.erb</tt> (les vues Erb sont intégrées par défaut
|
|
|
|
au +layout+ <tt>views/layout.erb</tt> quand ce fichier existe).
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Toute option que Sinatra ne comprend pas sera passée au moteur de rendu :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-03 21:27:51 +00:00
|
|
|
haml :index, :format => :html5
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Vous pouvez également définir des options par langage de template de façon
|
|
|
|
générale :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
set :haml, :format => html5
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-03 21:27:51 +00:00
|
|
|
haml :index
|
2011-03-06 21:01:52 +00:00
|
|
|
end
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Les options passées à la méthode de rendu prennent le pas sur les options
|
|
|
|
définies au moyen de +set+.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Options disponibles :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[locals]
|
|
|
|
Liste de variables locales passées au document. Pratique pour les vues
|
|
|
|
partielles.
|
|
|
|
Exemple : <tt>erb "<%= foo %>", :locals => {:foo => "bar"}</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[default_encoding]
|
|
|
|
Encodage de caractères à utiliser en cas d'incertitude. Par défaut, c'est
|
|
|
|
<tt>settings.default_encoding</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[views]
|
|
|
|
Dossier de vues dans lequel chercher les templates. Par défaut
|
|
|
|
<tt>settings.views</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[layout]
|
|
|
|
S'il faut ou non utiliser un +layout+ (+true+ or +false+). Indique le
|
2011-08-02 17:39:38 +00:00
|
|
|
template à utiliser lorsque c'est un symbole. Exemple : <tt>erb :index,
|
|
|
|
:layout => !request.xhr?</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[content_type]
|
|
|
|
Content-Type que le template produit, dépend par défaut du langage de
|
|
|
|
template.
|
2010-10-10 11:53:43 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[scope]
|
|
|
|
Contexte sous lequel effectuer le rendu du template. Par défaut il s'agit
|
|
|
|
de l'instance de l'application. Si vous changez cela, les variables
|
|
|
|
d'instance et les méthodes utilitaires ne seront pas disponibles.
|
2010-10-10 11:53:43 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
[layout_engine]
|
|
|
|
Moteur de rendu à utiliser pour le +layout+. Utile pour les langages ne
|
|
|
|
supportant pas les +layouts+. Il s'agit par défaut du moteur utilisé pour
|
|
|
|
le rendu du template. Exemple : <tt>set :rdoc, :layout_engine => :erb</tt>
|
2010-10-10 11:53:43 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Les templates sont supposés se trouver directement dans le dossier
|
|
|
|
<tt>./views</tt>. Pour utiliser un dossier de vues différent :
|
2010-10-10 11:53:43 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
set :views, settings.root + '/templates'
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Il est important de se souvenir que les templates sont toujours référencés
|
|
|
|
sous forme de symboles, même lorsqu'ils sont dans un sous-répertoire (dans
|
|
|
|
ce cas, utilisez <tt>:'sous_repertoire/template'</tt>). Il faut utiliser
|
|
|
|
un symbole car les méthodes de rendu évaluent le contenu des chaînes de
|
2011-05-03 21:27:51 +00:00
|
|
|
caractères au lieu de les considérer comme un chemin vers un fichier.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Langages de template disponibles
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Certains langages ont plusieurs implémentations. Pour préciser l'implémentation
|
2011-08-02 17:39:38 +00:00
|
|
|
à utiliser (et garantir l'aspect thread-safe), vous devez simplement l'avoir
|
|
|
|
chargée au préalable :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
require 'rdiscount' # ou require 'bluecloth'
|
|
|
|
get('/') { markdown :index }
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Haml
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {haml}[http://haml-lang.com/]
|
|
|
|
Extensions de fichier:: <tt>.haml</tt>
|
|
|
|
Exemple:: <tt>haml :index, :format => :html5</tt>
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Erb
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {erubis}[http://www.kuwata-lab.com/erubis/] ou
|
|
|
|
erb (inclus avec Ruby)
|
2011-08-02 17:39:38 +00:00
|
|
|
Extensions de fichier:: <tt>.erb</tt>, <tt>.rhtml</tt> ou <tt>.erubis</tt>
|
2011-05-03 21:27:51 +00:00
|
|
|
(Erubis seulement)
|
|
|
|
Exemple:: <tt>erb :index</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Builder
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {builder}[http://builder.rubyforge.org/]
|
|
|
|
Extensions de fichier:: <tt>.builder</tt>
|
2011-08-02 17:39:38 +00:00
|
|
|
Exemple:: <tt>builder { |xml| xml.em "salut" }</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Ce moteur accepte également un bloc pour des templates en ligne (voir exemple).
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Nokogiri
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {nokogiri}[http://nokogiri.org/]
|
|
|
|
Extensions de fichier:: <tt>.nokogiri</tt>
|
2011-09-15 11:38:00 +00:00
|
|
|
Exemple:: <tt>nokogiri { |xml| xml.em "salut" }</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Ce moteur accepte également un bloc pour des templates en ligne (voir exemple).
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Sass
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {sass}[http://sass-lang.com/]
|
|
|
|
Extensions de fichier:: <tt>.sass</tt>
|
|
|
|
Exemple:: <tt>sass :stylesheet, :style => :expanded</tt>
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates SCSS
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {sass}[http://sass-lang.com/]
|
|
|
|
Extensions de fichier:: <tt>.scss</tt>
|
|
|
|
Exemple:: <tt>scss :stylesheet, :style => :expanded</tt>
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates Less
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {less}[http://www.lesscss.org/]
|
|
|
|
Extensions de fichier:: <tt>.less</tt>
|
|
|
|
Exemple:: <tt>less :stylesheet</tt>
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Templates Liquid
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {liquid}[http://www.liquidmarkup.org/]
|
|
|
|
Extensions de fichier:: <tt>.liquid</tt>
|
|
|
|
Exemple:: <tt>liquid :index, :locals => { :key => 'value' }</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez appeler de méthodes Ruby (autres que +yield+) dans un
|
|
|
|
template Liquid, vous aurez sûrement à lui passer des variables locales.
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
=== Templates Markdown
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {rdiscount}[https://github.com/rtomayko/rdiscount],
|
|
|
|
{redcarpet}[https://github.com/tanoku/redcarpet],
|
|
|
|
{bluecloth}[http://deveiate.org/projects/BlueCloth],
|
|
|
|
{kramdown}[http://kramdown.rubyforge.org/] *ou*
|
|
|
|
{maruku}[http://maruku.rubyforge.org/]
|
2011-08-02 17:39:38 +00:00
|
|
|
Extensions de fichier:: <tt>.markdown</tt>, <tt>.mkd</tt> et <tt>.md</tt>
|
2011-05-03 21:27:51 +00:00
|
|
|
Exemple:: <tt>markdown :index, :layout_engine => :erb</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Il n'est pas possible d'appeler des méthodes depuis markdown, ni de lui
|
2011-05-03 21:27:51 +00:00
|
|
|
passer des variables locales. Par conséquent, il sera souvent utilisé en
|
|
|
|
combinaison avec un autre moteur de rendu :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :overview, :locals => { :text => markdown(:introduction) }
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Notez que vous pouvez également appeler la méthode +markdown+ au sein d'autres
|
2011-05-03 21:27:51 +00:00
|
|
|
templates :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
%h1 Hello From Haml !
|
|
|
|
%p= markdown(:greetings)
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez pas appeler de Ruby au sein de Markdown, vous ne pouvez
|
|
|
|
pas utiliser de +layouts+ écrits en Markdown. Toutefois, il est possible
|
2011-08-02 17:39:38 +00:00
|
|
|
d'utiliser un moteur de rendu différent pour le template et pour le +layout+
|
|
|
|
en utilisant l'option <tt>:layout_engine</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Templates Textile
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {RedCloth}[http://redcloth.org/]
|
|
|
|
Extensions de fichier:: <tt>.textile</tt>
|
|
|
|
Exemple:: <tt>textile :index, :layout_engine => :erb</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Il n'est pas possible d'appeler des méthodes depuis textile, ni de lui
|
2011-05-03 21:27:51 +00:00
|
|
|
passer des variables locales. Par conséquent, il sera souvent utilisé en
|
|
|
|
combinaison avec un autre moteur de rendu :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :overview, :locals => { :text => textile(:introduction) }
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Notez que vous pouvez également appeler la méthode +textile+ au sein d'autres
|
2011-05-02 12:44:49 +00:00
|
|
|
templates :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
%h1 Hello From Haml !
|
|
|
|
%p= textile(:greetings)
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez pas appeler de Ruby au sein de Textile, vous ne pouvez
|
|
|
|
pas utiliser de +layouts+ écrits en Textile. Toutefois, il est possible
|
2011-08-02 17:39:38 +00:00
|
|
|
d'utiliser un moteur de rendu différent pour le template et pour le +layout+
|
|
|
|
en utilisant l'option <tt>:layout_engine</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Templates RDoc
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {rdoc}[http://rdoc.rubyforge.org/]
|
|
|
|
Extensions de fichier:: <tt>.rdoc</tt>
|
2011-08-02 17:39:38 +00:00
|
|
|
Exemple:: <tt>rdoc :README, :layout_engine => :erb</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Il n'est pas possible d'appeler des méthodes depuis rdoc, ni de lui
|
2011-05-03 21:27:51 +00:00
|
|
|
passer des variables locales. Par conséquent, il sera souvent utilisé en
|
|
|
|
combinaison avec un autre moteur de rendu :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :overview, :locals => { :text => rdoc(:introduction) }
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Notez que vous pouvez également appeler la méthode +rdoc+ au sein d'autres
|
2011-05-02 12:44:49 +00:00
|
|
|
templates :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
%h1 Hello From Haml !
|
|
|
|
%p= rdoc(:greetings)
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez pas appeler de Ruby au sein de RDoc, vous ne pouvez
|
|
|
|
pas utiliser de +layouts+ écrits en RDoc. Toutefois, il est possible
|
2011-08-02 17:39:38 +00:00
|
|
|
d'utiliser un moteur de rendu différent pour le template et pour le +layout+
|
|
|
|
en utilisant l'option <tt>:layout_engine</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Templates Radius
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {radius}[http://radius.rubyforge.org/]
|
|
|
|
Extensions de fichier:: <tt>.radius</tt>
|
|
|
|
Exemple:: <tt>radius :index, :locals => { :key => 'value' }</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez pas appeler de méthodes Ruby depuis un template Radius,
|
2011-08-02 17:39:38 +00:00
|
|
|
vous aurez sûrement à lui passer des variables locales.
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
=== Templates Markaby
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {markaby}[http://markaby.github.com/]
|
|
|
|
Extensions de fichier:: <tt>.mab</tt>
|
|
|
|
Exemple:: <tt>markaby { h1 "Bienvenue !" }</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Ce moteur accepte également un bloc pour des templates en ligne (voir exemple).
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2010-11-05 12:59:49 +00:00
|
|
|
=== Templates Slim
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {slim}[http://slim-lang.com/]
|
|
|
|
Extensions de fichier:: <tt>.slim</tt>
|
|
|
|
Exemple:: <tt>slim :index</tt>
|
2010-11-05 12:59:49 +00:00
|
|
|
|
2011-04-15 09:51:35 +00:00
|
|
|
=== Templates Creole
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {creole}[https://github.com/minad/creole]
|
|
|
|
Extensions de fichier:: <tt>.creole</tt>
|
|
|
|
Exemple:: <tt>creole :wiki, :layout_engine => :erb</tt>
|
2011-04-15 09:51:35 +00:00
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Il n'est pas possible d'appeler des méthodes depuis creole, ni de lui
|
2011-05-03 21:27:51 +00:00
|
|
|
passer des variables locales. Par conséquent, il sera souvent utilisé en
|
|
|
|
combinaison avec un autre moteur de rendu :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
erb :overview, :locals => { :text => creole(:introduction) }
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Notez que vous pouvez également appeler la méthode +creole+ au sein d'autres
|
|
|
|
templates :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
%h1 Hello From Haml !
|
|
|
|
%p= creole(:greetings)
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Comme vous ne pouvez pas appeler de Ruby au sein de Creole, vous ne pouvez
|
|
|
|
pas utiliser de +layouts+ écrits en Creole. Toutefois, il est possible
|
2011-08-02 17:39:38 +00:00
|
|
|
d'utiliser un moteur de rendu différent pour le template et pour le +layout+
|
|
|
|
en utilisant l'option <tt>:layout_engine</tt>.
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
=== Templates CoffeeScript
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Dépendances:: {coffee-script}[https://github.com/josh/ruby-coffee-script]
|
|
|
|
et un {moyen d'exécuter javascript}[https://github.com/sstephenson/execjs/blob/master/README.md#readme]
|
|
|
|
Extensions de fichier:: <tt>.coffee</tt>
|
|
|
|
Exemple:: <tt>coffee :index</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2012-03-03 09:12:30 +00:00
|
|
|
=== Templates Yajl
|
|
|
|
|
|
|
|
Dépendances:: {yajl-ruby}[https://github.com/brianmario/yajl-ruby]
|
|
|
|
Extensions de fichier:: <tt>.yajl</tt>
|
|
|
|
Exemple:: <tt>yajl :index, :locals => { :key => 'qux' }, :callback => 'present', :variable => 'resource'</tt>
|
|
|
|
|
|
|
|
Le source du template est évalué en tant que chaine Ruby, puis la variable json
|
|
|
|
obtenue est convertie avec #to_json.
|
|
|
|
|
|
|
|
json = { :foo => 'bar' }
|
|
|
|
json[:baz] = key
|
|
|
|
|
|
|
|
Les options <tt>:callback</tt> et <tt>:variable</tt> peuvent être utilisées
|
|
|
|
pour décorer l'objet retourné.
|
|
|
|
|
|
|
|
var resource = {"foo":"bar","baz":"qux"}; present(resource);
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Templates embarqués
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
2011-05-02 12:44:49 +00:00
|
|
|
haml '%div.title Bonjour le monde'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-08-02 17:39:38 +00:00
|
|
|
Générera le code du template spécifié dans la chaîne de caractères.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
=== Accéder aux variables dans un Template
|
|
|
|
|
|
|
|
Un template est évalué dans le même contexte que l'endroit d'où il a été
|
|
|
|
appelé (gestionnaire de route). Les variables d'instance déclarées dans le
|
2011-05-02 12:44:49 +00:00
|
|
|
gestionnaire de route sont directement accessibles dans le template :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/:id' do
|
|
|
|
@foo = Foo.find(params[:id])
|
|
|
|
haml '%h1= @foo.nom'
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Alternativement, on peut passer un hash contenant des variables locales :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/:id' do
|
|
|
|
foo = Foo.find(params[:id])
|
|
|
|
haml '%h1= foo.nom', :locals => { :foo => foo }
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Ceci est généralement utilisé lorsque l'on veut utiliser un template comme
|
|
|
|
partiel (depuis un autre template) et qu'il est donc nécessaire d'adapter les
|
|
|
|
noms de variables.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
=== Templates dans le fichier source
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Des templates peuvent être définis dans le fichier source comme ceci :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
require 'sinatra'
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
haml :index
|
|
|
|
end
|
|
|
|
|
|
|
|
__END__
|
|
|
|
|
|
|
|
@@ layout
|
|
|
|
%html
|
|
|
|
= yield
|
|
|
|
|
|
|
|
@@ index
|
2011-05-02 12:44:49 +00:00
|
|
|
%div.title Bonjour le monde !
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
NOTE : Les templates du fichier source qui contient <tt>require 'sinatra'</tt>
|
2011-03-06 21:01:52 +00:00
|
|
|
sont automatiquement chargés. Si vous avez des templates dans d'autres
|
2011-05-02 12:44:49 +00:00
|
|
|
fichiers source, il faut explicitement les déclarer avec
|
2011-03-06 21:01:52 +00:00
|
|
|
<tt>enable :inline_templates</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Templates nommés
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Les templates peuvent aussi être définis grâce à la méthode de haut niveau
|
2011-05-02 12:44:49 +00:00
|
|
|
<tt>template</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
template :layout do
|
|
|
|
"%html\n =yield\n"
|
|
|
|
end
|
|
|
|
|
|
|
|
template :index do
|
2011-05-02 12:44:49 +00:00
|
|
|
'%div.title Bonjour le monde !'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
haml :index
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Si un template nommé "layout" existe, il sera utilisé à chaque fois qu'un
|
|
|
|
template sera affiché. Vous pouvez désactivez les layouts au cas par cas en
|
|
|
|
passant <tt>:layout => false</tt> ou bien les désactiver par défaut au moyen
|
2011-05-02 12:44:49 +00:00
|
|
|
de <tt>set :haml, :layout => false</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
haml :index, :layout => !request.xhr?
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Associer des extensions de fichier
|
|
|
|
|
|
|
|
Pour associer une extension de fichier avec un moteur de rendu, utilisez
|
|
|
|
<tt>Tilt.register</tt>. Par exemple, si vous désirez utiliser l'extension
|
|
|
|
de fichier +tt+ pour les templates Textile, vous pouvez faire comme suit :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Tilt.register :tt, Tilt[:textile]
|
|
|
|
|
|
|
|
=== Ajouter son propre moteur de rendu
|
|
|
|
|
|
|
|
En premier lieu, déclarez votre moteur de rendu avec Tilt, ensuite créez
|
|
|
|
votre méthode de rendu :
|
|
|
|
|
|
|
|
Tilt.register :monmoteur, MonMerveilleurMoteurDeRendu
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
helpers do
|
2011-03-06 21:01:52 +00:00
|
|
|
def monmoteur(*args) render(:monmoteur, *args) end
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
get '/' do
|
|
|
|
monmoteur :index
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Utilisera <tt>./views/index.monmoteur</tt>. Voir
|
|
|
|
https://github.com/rtomayko/tilt pour en savoir plus sur Tilt.
|
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Filtres
|
|
|
|
|
2011-09-02 12:22:05 +00:00
|
|
|
Les filtres before sont exécutés avant chaque requête, dans le même contexte
|
|
|
|
que les routes, et permettent de modifier la requête et sa réponse. Les
|
|
|
|
variables d'instance déclarées dans les filtres sont accessibles au niveau
|
|
|
|
des routes et des templates :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
before do
|
2011-05-02 12:44:49 +00:00
|
|
|
@note = 'Coucou !'
|
2010-09-21 06:46:20 +00:00
|
|
|
request.path_info = '/foo/bar/baz'
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/foo/*' do
|
2011-05-02 12:44:49 +00:00
|
|
|
@note #=> 'Coucou !'
|
2010-09-21 06:46:20 +00:00
|
|
|
params[:splat] #=> 'bar/baz'
|
|
|
|
end
|
|
|
|
|
2011-09-02 12:22:05 +00:00
|
|
|
Les filtres after sont exécutés après chaque requête à l'intérieur du même
|
|
|
|
contexte et permettent de modifier la requête et sa réponse. Les variables
|
|
|
|
d'instance déclarées dans les filtres before ou les routes sont accessibles
|
|
|
|
au niveau des filtres after :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
after do
|
|
|
|
puts response.status
|
|
|
|
end
|
|
|
|
|
2011-09-02 12:22:05 +00:00
|
|
|
Note : Le corps de la réponse n'est pas disponible au niveau du filtre after
|
|
|
|
car il ne sera généré que plus tard (sauf dans le cas où vous utilisez la
|
|
|
|
méthode +body+ au lieu de simplement renvoyer une chaine depuis vos routes).
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-02 12:22:05 +00:00
|
|
|
Les filtres peuvent être associés à un masque, ce qui permet de limiter leur
|
|
|
|
exécution aux cas où la requête correspond à ce masque :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
before '/secret/*' do
|
|
|
|
authentification!
|
|
|
|
end
|
|
|
|
|
|
|
|
after '/faire/:travail' do |travail|
|
|
|
|
session[:dernier_travail] = travail
|
|
|
|
end
|
|
|
|
|
2011-09-02 12:22:05 +00:00
|
|
|
Tout comme les routes, les filtres acceptent également des conditions :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
before :agent => /Songbird/ do
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
|
|
|
after '/blog/*', :host_name => 'example.com' do
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
|
|
|
== Helpers
|
|
|
|
|
|
|
|
Utilisez la méthode de haut niveau <tt>helpers</tt> pour définir des routines
|
|
|
|
qui seront accessibles dans vos gestionnaires de route et dans vos templates :
|
|
|
|
|
|
|
|
helpers do
|
|
|
|
def bar(nom)
|
|
|
|
"#{nom}bar"
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/:nom' do
|
|
|
|
bar(params[:nom])
|
|
|
|
end
|
|
|
|
|
2012-03-06 00:16:43 +00:00
|
|
|
Vous pouvez aussi définir les méthodes helper dans un module séparé :
|
|
|
|
|
|
|
|
module FooUtils
|
|
|
|
def foo(nom) "#{nom}foo" end
|
|
|
|
end
|
|
|
|
|
|
|
|
module BarUtils
|
|
|
|
def bar(nom) "#{nom}bar" end
|
|
|
|
end
|
|
|
|
|
|
|
|
helpers FooUtils, BarUtils
|
|
|
|
|
|
|
|
Cela a le même résultat que d'inclure les modules dans la classe de
|
|
|
|
l'application.
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Utiliser les sessions
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Une session est utilisée pour conserver un état entre les requêtes. Une fois
|
2011-03-06 21:01:52 +00:00
|
|
|
activées, vous avez un +hash+ de session par session utilisateur :
|
|
|
|
|
|
|
|
enable :sessions
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
"valeur = " << session[:valeur].inspect
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/:value' do
|
|
|
|
session[:valeur] = params[:valeur]
|
|
|
|
end
|
|
|
|
|
|
|
|
Notez que <tt>enable :sessions</tt> enregistre en fait toutes les données dans
|
|
|
|
un +cookie+. Ce n'est pas toujours ce que vous voulez (enregistrer beaucoup de
|
|
|
|
données va augmenter le traffic par exemple). Vous pouvez utiliser n'importe
|
|
|
|
quel +middleware+ Rack de session afin d'éviter cela. N'utiliser *pas*
|
|
|
|
<tt>enable :sessions</tt> dans ce cas mais charger le +middleware+ de votre
|
|
|
|
choix comme vous le feriez pour n'importe quel autre +middleware+ :
|
|
|
|
|
|
|
|
use Rack::Session::Pool, :expire_after => 2592000
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
"valeur = " << session[:valeur].inspect
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/:value' do
|
|
|
|
session[:valeur] = params[:valeur]
|
|
|
|
end
|
|
|
|
|
2011-04-05 21:20:17 +00:00
|
|
|
Pour renforcer la sécurité, les données de session dans le cookie sont signées
|
|
|
|
avec une clé secrète de session. Une clé secrète est générée pour vous au
|
|
|
|
hasard par Sinatra. Toutefois, comme cette clé change à chaque démarrage de
|
|
|
|
votre application, vous pouvez définir cette clé vous-même afin que toutes
|
2011-05-02 12:44:49 +00:00
|
|
|
les instances de votre application la partage :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
set :session_secret, 'super secret'
|
|
|
|
|
|
|
|
Si vous souhaitez avoir plus de contrôle, vous pouvez également enregistrer un
|
2011-05-02 12:44:49 +00:00
|
|
|
+hash+ avec des options lors de la configuration de +sessions+ :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
set :sessions, :domain => 'foo.com'
|
|
|
|
|
2011-07-05 16:28:11 +00:00
|
|
|
=== Halt
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Pour arrêter immédiatement la requête dans un filtre ou un gestionnaire de
|
2011-05-02 12:44:49 +00:00
|
|
|
route :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
halt
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
Vous pouvez aussi passer le code retour ...
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
halt 410
|
|
|
|
|
|
|
|
Ou le texte ...
|
|
|
|
|
|
|
|
halt 'Ceci est le texte'
|
|
|
|
|
|
|
|
Ou les deux ...
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
halt 401, 'Partez !'
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
Ainsi que les entêtes ...
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
halt 402, {'Content-Type' => 'text/plain'}, 'revanche'
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Bien sûr il est possible de combiner un template avec +halt+ :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
halt erb(:erreur)
|
|
|
|
|
2011-07-05 16:28:11 +00:00
|
|
|
=== Passer
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
Une route peut passer le relais aux autres routes qui correspondent également
|
2011-05-02 12:44:49 +00:00
|
|
|
avec <tt>pass</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/devine/:qui' do
|
|
|
|
pass unless params[:qui] == 'Frank'
|
2011-05-02 12:44:49 +00:00
|
|
|
"Tu m'as eu !"
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
get '/devine/*' do
|
2011-05-02 12:44:49 +00:00
|
|
|
'Manqué !'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
On sort donc immédiatement de ce gestionnaire et on continue à chercher,
|
|
|
|
dans les masques suivants, le prochain qui correspond à la requête.
|
|
|
|
Si aucun des masques suivants ne correspond, un code 404 est retourné.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Déclencher une autre route
|
|
|
|
|
|
|
|
Parfois, +pass+ n'est pas ce que vous recherchez, au lieu de cela vous
|
|
|
|
souhaitez obtenir le résultat d'une autre route. Pour cela, utilisez
|
|
|
|
simplement +call+ :
|
|
|
|
|
|
|
|
get '/foo' do
|
2011-04-17 10:43:22 +00:00
|
|
|
status, headers, body = call env.merge("PATH_INFO" => '/bar')
|
2011-04-17 10:56:03 +00:00
|
|
|
[status, headers, body.map(&:upcase)]
|
2011-03-06 21:01:52 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
get '/bar' do
|
|
|
|
"bar"
|
|
|
|
end
|
|
|
|
|
|
|
|
Notez que dans l'exemple ci-dessus, vous faciliterez les tests et améliorerez
|
|
|
|
la performance en déplaçant simplement <tt>"bar"</tt> dans un +helper+
|
|
|
|
utilisé à la fois par <tt>/foo</tt> et <tt>/bar</tt>.
|
|
|
|
|
|
|
|
Si vous souhiatez que la requête soit envoyée à la même instance de
|
|
|
|
l'application plutôt qu'à une copie, utilisez <tt>call!</tt> au lieu de
|
|
|
|
<tt>call</tt>.
|
|
|
|
|
|
|
|
Lisez la spécification Rack si vous souhaitez en savoir plus sur
|
|
|
|
<tt>call</tt>.
|
|
|
|
|
|
|
|
=== Définir le corps, le code retour et les entêtes
|
|
|
|
|
|
|
|
Il est possible et recommandé de définir le code retour et le corps de la
|
|
|
|
réponse au moyen de la valeur de retour d'un bloc définissant une route.
|
|
|
|
Quoiqu'il en soit, dans certains cas vous pourriez avoir besoin de définir
|
|
|
|
le coprs de la réponse à un moment arbitraire de l'exécution. Vous pouvez le
|
|
|
|
faire au moyen de la méthode +body+. Si vous faites ainsi, vous pouvez alors
|
|
|
|
utiliser cette même méthode pour accéder au corps de la réponse :
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
body "bar"
|
|
|
|
end
|
|
|
|
|
|
|
|
after do
|
|
|
|
puts body
|
|
|
|
end
|
|
|
|
|
|
|
|
Il est également possible de passer un bloc à +body+, qui sera exécuté par le
|
|
|
|
gestionnaire Rack (ceci peut être utilisé pour implémenter un +streaming+,
|
|
|
|
voir "Valeurs de retour").
|
|
|
|
|
|
|
|
Pareillement au corps de la réponse, vous pouvez également définir le code
|
|
|
|
retour et les entêtes :
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
status 418
|
|
|
|
headers \
|
2011-08-09 10:26:53 +00:00
|
|
|
"Allow" => "BREW, POST, GET, PROPFIND, WHEN",
|
2011-03-06 21:01:52 +00:00
|
|
|
"Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
|
2011-05-03 21:27:51 +00:00
|
|
|
body "Je suis une théière !"
|
2011-03-06 21:01:52 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
Comme +body+, +headers+ et +status+ peuvent être utilisés sans arguments
|
|
|
|
pour accéder à leurs valeurs.
|
|
|
|
|
2011-09-01 15:32:10 +00:00
|
|
|
=== Faire du streaming
|
|
|
|
|
|
|
|
Il y a des cas où vous voulez commencer à renvoyer des données pendant que
|
|
|
|
vous êtes en train de générer le reste de la réponse. Dans les cas les plus
|
|
|
|
extrèmes, vous souhaitez continuer à envoyer des données tant que le client
|
|
|
|
n'abandonne pas la connection. Vous pouvez alors utiliser le helper +stream+
|
|
|
|
pour éviter de créer votre propre système :
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
stream do |out|
|
|
|
|
out << "Ca va être hallu -\n"
|
|
|
|
sleep 0.5
|
|
|
|
out << " (attends la suite) \n"
|
|
|
|
sleep 1
|
|
|
|
out << "- cinant !\n"
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
Cela permet d'implémenter des API de streaming ou de
|
|
|
|
{Server Sent Events}[http://dev.w3.org/html5/eventsource/] et peut servir de
|
|
|
|
base pour des {WebSockets}[http://en.wikipedia.org/wiki/WebSocket]. Vous
|
|
|
|
pouvez aussi l'employer pour augmenter le débit quand une partie du contenu
|
|
|
|
provient d'une resource lente.
|
|
|
|
|
|
|
|
Le fonctionnement du streaming, notamment le nombre de requêtes simultanées,
|
|
|
|
dépend énormément du serveur web utilisé. Certains ne prennent pas du tout en
|
|
|
|
charge le streaming (WEBRick par exemple). Lorsque le serveur ne gère pas le
|
|
|
|
streaming, la partie body de la réponse sera envoyée au client en une seule
|
2012-03-03 10:46:08 +00:00
|
|
|
fois, après que l'exécution du bloc passé au helper +stream+ sera terminée. Le
|
|
|
|
streaming ne fonctionne pas du tout avec Shotgun.
|
2011-09-01 15:32:10 +00:00
|
|
|
|
2011-09-01 17:10:31 +00:00
|
|
|
En utilisant le helper +stream+ avec le paramètre +keep_open+, il n'appelera
|
|
|
|
pas la méthode +close+ du flux, vous laissant la possibilité de le fermer à
|
|
|
|
tout moment au cours de l'exécution. Ceci ne fonctionne qu'avec les serveurs
|
2011-09-01 15:32:10 +00:00
|
|
|
evented (ie non threadés) tels que Thin et Rainbows. Les autres serveurs
|
2011-09-02 11:35:37 +00:00
|
|
|
fermeront malgré tout le flux :
|
2011-09-01 15:32:10 +00:00
|
|
|
|
|
|
|
set :server, :thin
|
|
|
|
connections = []
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
# conserve le flux ouvert
|
2011-09-01 17:10:31 +00:00
|
|
|
stream(:keep_open) { |out| connections << out }
|
2011-09-01 15:32:10 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
post '/' do
|
|
|
|
# écrit dans tous les flux ouverts
|
|
|
|
connections.each { |out| out << params[:message] << "\n" }
|
|
|
|
"message sent"
|
|
|
|
end
|
|
|
|
|
2011-04-05 21:20:17 +00:00
|
|
|
=== Journalisation (Logging)
|
|
|
|
|
|
|
|
Dans le contexte de la requête, la méthode utilitaire +logger+ expose une
|
2011-05-02 12:44:49 +00:00
|
|
|
instance de +logger+ :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
logger.info "chargement des données"
|
|
|
|
# ...
|
|
|
|
end
|
|
|
|
|
|
|
|
Ce +logger+ va automatiquement prendre en compte les paramètres de
|
|
|
|
configuration pour la journalisation de votre gestionnaire Rack. Si la
|
|
|
|
journalisation est désactivée, cette méthode renverra un objet factice et
|
|
|
|
vous n'avez pas à vous en inquiéter dans vos routes en le filtrant.
|
|
|
|
|
|
|
|
Notez que la journalisation est seulement activée par défaut pour
|
|
|
|
<tt>Sinatra::Application</tt>, donc si vous héritez de <tt>Sinatra::Base</tt>,
|
2011-05-02 12:44:49 +00:00
|
|
|
vous aurez à l'activer vous-même :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
class MonApp < Sinatra::Base
|
2012-03-03 10:37:47 +00:00
|
|
|
configure :production, :development do
|
2011-04-05 21:20:17 +00:00
|
|
|
enable :logging
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2012-03-06 00:38:49 +00:00
|
|
|
Si vous souhaitez utiliser votre propre logger, vous devez définir le paramètre
|
|
|
|
+logging+ à +nil+ pour être certain qu'aucun middleware de logging ne sera
|
|
|
|
installé (notez toutefois que +logger+ renverra alors +nil+). Dans ce cas,
|
|
|
|
Sinatra utilisera ce qui sera présent dans <tt>env['rack.logger']</tt>.
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Types Mime
|
|
|
|
|
|
|
|
Quand vous utilisez <tt>send_file</tt> ou des fichiers statiques, vous
|
|
|
|
pouvez rencontrer des types mime que Sinatra ne connaît pas. Utilisez
|
|
|
|
+mime_type+ pour les déclarer par extension de fichier :
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
configure do
|
|
|
|
mime_type :foo, 'text/foo'
|
|
|
|
end
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
Vous pouvez également les utiliser avec la méthode +content_type+ :
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
content_type :foo
|
|
|
|
"foo foo foo"
|
|
|
|
end
|
|
|
|
|
|
|
|
=== Former des URLs
|
|
|
|
|
|
|
|
Pour former des URLs, vous devriez utiliser la méthode +url+, par exemple en
|
|
|
|
Haml :
|
|
|
|
|
|
|
|
%a{:href => url('/foo')} foo
|
|
|
|
|
|
|
|
Cela prend en compte les proxy inverse et les routeurs Rack, s'ils existent.
|
|
|
|
|
|
|
|
Cette méthode est également disponible sous l'alias +to+ (voir ci-dessous
|
|
|
|
pour un exemple).
|
|
|
|
|
|
|
|
=== Redirection du navigateur
|
|
|
|
|
|
|
|
Vous pouvez déclencher une redirection du navigateur avec la méthode
|
|
|
|
+redirect+ :
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
redirect to('/bar')
|
|
|
|
end
|
|
|
|
|
|
|
|
Tout paramètre additionnel est géré comme des arguments pour la méthode
|
|
|
|
+halt+ :
|
|
|
|
|
|
|
|
redirect to('/bar'), 303
|
|
|
|
redirect 'http://google.com', 'mauvais endroit mon pote'
|
|
|
|
|
|
|
|
Vous pouvez aussi rediriger vers la page dont l'utilisateur venait au moyen de
|
2011-05-02 12:44:49 +00:00
|
|
|
<tt>redirect back</tt> :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
"<a href='/bar'>faire quelque chose</a>"
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/bar' do
|
|
|
|
faire_quelque_chose
|
|
|
|
redirect back
|
|
|
|
end
|
|
|
|
|
|
|
|
Pour passer des arguments à une redirection, ajoutez-les soit à la requête :
|
|
|
|
|
|
|
|
redirect to('/bar?sum=42')
|
|
|
|
|
|
|
|
Ou bien utilisez une session :
|
|
|
|
|
2011-08-23 10:49:23 +00:00
|
|
|
enable :sessions
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
session[:secret] = 'foo'
|
|
|
|
redirect to('/bar')
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/bar' do
|
|
|
|
session[:secret]
|
|
|
|
end
|
|
|
|
|
|
|
|
=== Contrôle du cache
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Définir correctement vos entêtes à la base pour un bon cache HTTP.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
Vous pouvez facilement définir l'entête Cache-Control de la manière suivante :
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
cache_control :public
|
|
|
|
"met le en cache !"
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Conseil de pro : définir le cache dans un filtre +before+ :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
before do
|
|
|
|
cache_control :public, :must_revalidate, :max_age => 60
|
|
|
|
end
|
|
|
|
|
|
|
|
Si vous utilisez la méthode +expires+ pour définir l'entête correspondant,
|
|
|
|
<tt>Cache-Control</tt> sera alors défini automatiquement :
|
|
|
|
|
|
|
|
before do
|
|
|
|
expires 500, :public, :must_revalidate
|
|
|
|
end
|
|
|
|
|
2011-09-01 15:38:40 +00:00
|
|
|
Pour utiliser correctement les caches, vous devriez utiliser +etag+ ou
|
2011-03-06 21:01:52 +00:00
|
|
|
+last_modified+. Il est recommandé d'utiliser ces méthodes *avant* de faire
|
2011-05-03 21:27:51 +00:00
|
|
|
d'importantes modifications, car elles vont immédiatement déclencher la réponse
|
2011-05-02 12:44:49 +00:00
|
|
|
si le client a déjà la version courante dans son cache :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
get '/article/:id' do
|
|
|
|
@article = Article.find params[:id]
|
|
|
|
last_modified @article.updated_at
|
|
|
|
etag @article.sha1
|
|
|
|
erb :article
|
|
|
|
end
|
|
|
|
|
|
|
|
Il est également possible d'utiliser un
|
2011-05-02 12:44:49 +00:00
|
|
|
{weak ETag}[http://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation] :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
etag @article.sha1, :weak
|
|
|
|
|
|
|
|
Ces méthodes ne sont pas chargées de mettre des données en cache, mais elles
|
|
|
|
fournissent les informations nécessaires pour votre cache. Si vous êtes à la
|
2011-09-01 15:38:40 +00:00
|
|
|
recherche de solutions rapides pour un reverse-proxy de cache, essayez
|
2011-05-02 12:44:49 +00:00
|
|
|
{rack-cache}[http://rtomayko.github.com/rack-cache/] :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
require "rack/cache"
|
|
|
|
require "sinatra"
|
|
|
|
|
|
|
|
use Rack::Cache
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
cache_control :public, :max_age => 36000
|
|
|
|
sleep 5
|
|
|
|
"hello"
|
|
|
|
end
|
|
|
|
|
2011-09-15 12:18:32 +00:00
|
|
|
Utilisez le paramètre <tt>:static_cache_control</tt> pour ajouter l'information
|
|
|
|
d'en-tête <tt>Cache-Control</tt> (voir plus loin).
|
|
|
|
|
2012-03-03 10:31:52 +00:00
|
|
|
D'après la RFC 2616, votre application devrait se comporter différement lorsque
|
|
|
|
l'en-tête If-Match ou If-None-Match est défini à <tt>*</tt> en tenant compte du
|
|
|
|
fait que la resource demandée existe déjà ou pas. Sinatra considère que les
|
|
|
|
requêtes portant sur des resources sûres (tel que get) ou idempotentes (tel que
|
|
|
|
put) existent déjà et pour les autres resources (par exemple dans le cas
|
|
|
|
de requêtes post) qu'il s'agit de nouvelles resources. Vous pouvez modifier ce
|
|
|
|
comportement en passant une option <tt>:new_resource</tt> :
|
|
|
|
|
|
|
|
get '/create' do
|
|
|
|
etag '', :new_resource => true
|
|
|
|
Article.create
|
|
|
|
erb :new_article
|
|
|
|
end
|
|
|
|
|
|
|
|
Si vous souhaitez utilisez un ETag faible, utilisez l'option <tt>:kind</tt> :
|
|
|
|
|
|
|
|
etag '', :new_resource => true, :kind => :weak
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Envoyer des fichiers
|
|
|
|
|
|
|
|
Pour envoyer des fichiers, vous pouvez utiliser la méthode
|
|
|
|
<tt>send_file</tt> :
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
send_file 'foo.png'
|
|
|
|
end
|
|
|
|
|
|
|
|
Quelques options sont également acceptées :
|
|
|
|
|
|
|
|
send_file 'foo.png', :type => :jpg
|
|
|
|
|
|
|
|
Les options sont :
|
|
|
|
|
|
|
|
[filename]
|
|
|
|
le nom du fichier dans la réponse, par défaut le nom du fichier envoyé.
|
|
|
|
|
|
|
|
[last_modified]
|
|
|
|
valeur pour l'entête Last-Modified, par défaut la date de modification du
|
|
|
|
fichier
|
|
|
|
|
|
|
|
[type]
|
|
|
|
type de contenu à utiliser, deviné à partir de l'extension de fichier si
|
|
|
|
absent
|
|
|
|
|
|
|
|
[disposition]
|
|
|
|
utilisé pour Content-Disposition, les valuers possibles étant : +nil+ (par
|
|
|
|
défaut), <tt>:attachment</tt> et <tt>:inline</tt>
|
|
|
|
|
|
|
|
[length]
|
|
|
|
entête Content-Length, par défaut la taille du fichier
|
|
|
|
|
2012-03-06 00:10:07 +00:00
|
|
|
[status]
|
|
|
|
code état à renvoyer. Utile quand un fichier statique sert de page d'erreur.
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Si le gestionnaire Rack le supporte, d'autres moyens que le +streaming+ via le
|
|
|
|
processus Ruby seront utilisés. Si vous utilisez cette méthode, Sinatra gérera
|
|
|
|
automatiquement les requêtes de type +range+.
|
|
|
|
|
2011-07-05 16:28:11 +00:00
|
|
|
=== Accéder à l'objet requête
|
2010-10-12 19:35:37 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
L'objet correspondant à la requête envoyée peut être récupéré dans le contexte
|
|
|
|
de la requête (filtres, routes, gestionnaires d'erreur) au moyen de la méthode
|
2011-05-02 12:44:49 +00:00
|
|
|
+request+ :
|
2010-10-12 19:35:37 +00:00
|
|
|
|
|
|
|
# application tournant à l'adresse http://exemple.com/exemple
|
|
|
|
get '/foo' do
|
2011-04-05 21:20:17 +00:00
|
|
|
t = %w[text/css text/html application/javascript]
|
|
|
|
request.accept # ['text/html', '*/*']
|
|
|
|
request.accept? 'text/xml' # true
|
|
|
|
request.preferred_type(t) # 'text/html'
|
|
|
|
request.body # corps de la requête envoyée par le client
|
|
|
|
# (voir ci-dessous)
|
|
|
|
request.scheme # "http"
|
|
|
|
request.script_name # "/exemple"
|
|
|
|
request.path_info # "/foo"
|
|
|
|
request.port # 80
|
|
|
|
request.request_method # "GET"
|
|
|
|
request.query_string # ""
|
|
|
|
request.content_length # taille de request.body
|
|
|
|
request.media_type # type de média pour request.body
|
|
|
|
request.host # "exemple.com"
|
|
|
|
request.get? # true (méthodes similaires pour les autres
|
|
|
|
# verbes HTTP)
|
|
|
|
request.form_data? # false
|
|
|
|
request["UN_ENTETE"] # valeur de l'entête UN_ENTETE
|
|
|
|
request.referer # référant du client ou '/'
|
|
|
|
request.user_agent # user agent (utilisé par la condition :agent)
|
|
|
|
request.cookies # tableau contenant les cookies du navigateur
|
|
|
|
request.xhr? # requête AJAX ?
|
|
|
|
request.url # "http://exemple.com/exemple/foo"
|
|
|
|
request.path # "/exemple/foo"
|
|
|
|
request.ip # adresse IP du client
|
|
|
|
request.secure? # false
|
|
|
|
request.forwarded? # vrai (si on est derrière un proxy inverse)
|
|
|
|
request.env # tableau brut de l'environnement fourni par
|
|
|
|
# Rack
|
2010-10-12 19:35:37 +00:00
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Certaines options, telles que <tt>script_name</tt> ou <tt>path_info</tt>
|
2011-05-02 12:44:49 +00:00
|
|
|
peuvent également être modifiées :
|
2010-10-12 19:35:37 +00:00
|
|
|
|
|
|
|
before { request.path_info = "/" }
|
|
|
|
|
|
|
|
get "/" do
|
|
|
|
"toutes les requêtes arrivent ici"
|
|
|
|
end
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
<tt>request.body</tt> est un objet IO ou StringIO :
|
2010-10-12 19:35:37 +00:00
|
|
|
|
|
|
|
post "/api" do
|
|
|
|
request.body.rewind # au cas où il a déjà été lu
|
|
|
|
donnees = JSON.parse request.body.read
|
2011-05-02 12:44:49 +00:00
|
|
|
"Bonjour #{donnees['nom']} !"
|
2010-10-12 19:35:37 +00:00
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Fichiers joints
|
|
|
|
|
|
|
|
Vous pouvez utiliser la méthode +attachment+ pour indiquer au navigateur que
|
2011-05-02 12:44:49 +00:00
|
|
|
la réponse devrait être stockée sur le disque plutôt qu'affichée :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
attachment
|
|
|
|
"enregistre-le !"
|
|
|
|
end
|
|
|
|
|
|
|
|
Vous pouvez également lui passer un nom de fichier :
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
attachment "info.txt"
|
|
|
|
"enregistre-le !"
|
|
|
|
end
|
|
|
|
|
2011-09-01 15:52:22 +00:00
|
|
|
=== Gérer Date et Time
|
|
|
|
|
|
|
|
Sinatra fourni un helper +time_for+ pour convertir une valeur donnée en
|
|
|
|
objet +Time+. Il peut aussi faire la conversion à partir d'objets +DateTime+,
|
2011-09-02 11:35:37 +00:00
|
|
|
+Date+ ou de classes similaires :
|
2011-09-01 15:52:22 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
pass if Time.now > time_for('Dec 23, 2012')
|
|
|
|
"encore temps"
|
|
|
|
end
|
|
|
|
|
|
|
|
Cette méthode est utilisée en interne par +expires+, +last_modified+ et
|
|
|
|
consorts. Par conséquent, vous pouvez très facilement étendre le
|
|
|
|
fonctionnement de ces méthodes en surchargeant le helper +time_for+ dans
|
|
|
|
votre application :
|
|
|
|
|
|
|
|
helpers do
|
|
|
|
def time_for(value)
|
|
|
|
case value
|
|
|
|
when :yesterday then Time.now - 24*60*60
|
|
|
|
when :tomorrow then Time.now + 24*60*60
|
|
|
|
else super
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
last_modified :yesterday
|
|
|
|
expires :tomorrow
|
|
|
|
"salut"
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Chercher les fichiers de templates
|
|
|
|
|
|
|
|
La méthode <tt>find_template</tt> est utilisée pour trouver les fichiers de
|
|
|
|
templates à générer :
|
|
|
|
|
|
|
|
find_template settings.views, 'foo', Tilt[:haml] do |file|
|
|
|
|
puts "pourrait être #{file}"
|
|
|
|
end
|
|
|
|
|
|
|
|
Ce n'est pas très utilise. En revanche, il est utile de pouvoir surcharger
|
|
|
|
cette méthode afin de définir son propre mécanisme de recherche. Par exemple,
|
|
|
|
vous pouvez utiliser plus d'un répertoire de vues :
|
|
|
|
|
|
|
|
set :views, ['views', 'templates']
|
|
|
|
|
|
|
|
helpers do
|
|
|
|
def find_template(views, name, engine, &block)
|
|
|
|
Array(views).each { |v| super(v, name, engine, &block) }
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
Un autre exemple est d'utiliser des répertoires différents pour des moteurs
|
|
|
|
de rendu différents :
|
|
|
|
|
|
|
|
set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views'
|
|
|
|
|
|
|
|
helpers do
|
|
|
|
def find_template(views, name, engine, &block)
|
|
|
|
_, folder = views.detect { |k,v| engine == Tilt[k] }
|
|
|
|
folder ||= views[:default]
|
|
|
|
super(folder, name, engine, &block)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
Vous pouvez également écrire cela dans une extension et la partager avec
|
|
|
|
d'autres !
|
|
|
|
|
|
|
|
Notez que <tt>find_template</tt> ne vérifie pas que le fichier existe mais
|
|
|
|
va plutôt exécuter le bloc pour tous les chemins possibles. Cela n'induit pas
|
|
|
|
un problème de performance dans le sens où +render+ va utiliser +break+ dès
|
|
|
|
qu'un fichier est trouvé. De plus, l'emplacement des templates (et leur
|
|
|
|
contenu) est mis en cache si vous n'êtes pas en mode développement. Vous
|
|
|
|
devriez garder cela en tête si vous écrivez une méthode vraiment dingue.
|
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Configuration
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Lancé une seule fois au démarrage de tous les environnements :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
configure do
|
2011-03-06 21:01:52 +00:00
|
|
|
# définir un paramètre
|
|
|
|
set :option, 'value'
|
|
|
|
|
|
|
|
# définir plusieurs paramètre
|
|
|
|
set :a => 1, :b => 2
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
# identique à "set :option, true"
|
2011-03-06 21:01:52 +00:00
|
|
|
enable :option
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
# identique à "set :option, false""
|
2011-03-06 21:01:52 +00:00
|
|
|
disable :option
|
|
|
|
|
|
|
|
# vous pouvez également avoir des paramètres dynamiques avec des blocs
|
|
|
|
set(:css_dir) { File.join(views, 'css') }
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
Lancé si l'environnement (variable d'environnement RACK_ENV) est défini comme
|
2011-05-02 12:44:49 +00:00
|
|
|
<tt>:production</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
configure :production do
|
|
|
|
...
|
|
|
|
end
|
|
|
|
|
|
|
|
Lancé si l'environnement est <tt>:production</tt> ou
|
2011-05-02 12:44:49 +00:00
|
|
|
<tt>:test</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
configure :production, :test do
|
|
|
|
...
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Vous pouvez accéder à ces paramètres via <tt>settings</tt> :
|
|
|
|
|
|
|
|
configure do
|
|
|
|
set :foo, 'bar'
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
settings.foo? # => true
|
|
|
|
settings.foo # => 'bar'
|
|
|
|
...
|
|
|
|
end
|
|
|
|
|
2012-03-03 09:24:16 +00:00
|
|
|
=== Se protéger des attaques
|
|
|
|
|
|
|
|
Sinatra utilise {Rack::Protection}[https://github.com/rkh/rack-protection#readme]
|
|
|
|
pour protéger votre application contre les principales attaques opportunistes.
|
|
|
|
Vous pouvez très simplement désactiver cette fonctionnalité (ce qui devrait
|
|
|
|
améliorer les performances) :
|
|
|
|
|
|
|
|
disable :protection
|
|
|
|
|
|
|
|
Pour désactiver seulement un type de protection, vous pouvez définir +protection+
|
2012-03-06 00:04:22 +00:00
|
|
|
avec un hash d'options :
|
2012-03-03 09:24:16 +00:00
|
|
|
|
|
|
|
set :protection, :except => :path_traversal
|
|
|
|
|
|
|
|
Vous pouvez également lui passer un tableau pour désactiver plusieurs types de
|
|
|
|
protection :
|
|
|
|
|
|
|
|
set :protection, :except => [:path_traversal, :session_hijacking]
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Paramètres disponibles
|
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[absolute_redirects] Si désactivé, Sinatra permettra les redirections
|
|
|
|
relatives. Toutefois, Sinatra ne sera plus conforme à la
|
|
|
|
RFC 2616 (HTTP 1.1), qui n'autorise que les redirections
|
|
|
|
absolues.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
Activez si votre application tourne derrière un proxy
|
|
|
|
inverse qui n'a pas été correctement configuré. Notez
|
|
|
|
que la méthode +url+ continuera de produire des URLs
|
|
|
|
absolues, sauf si vous lui passez +false+ comme second
|
|
|
|
argument.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
Désactivé par défaut.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[add_charsets] types mime pour lesquels la méthode
|
|
|
|
<tt>content_type</tt> va automatiquement ajouter
|
|
|
|
l'information du +charset+.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
Vous devriez lui ajouter des valeurs plutôt que de
|
|
|
|
l'écraser :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
settings.add_charsets << "application/foobar"
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[app_file] chemin pour le fichier de l'application principale,
|
|
|
|
utilisé pour détecter la racine du projet, les dossiers
|
|
|
|
public et vues, et les templates en ligne.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[bind] adresse IP sur laquelle se brancher
|
|
|
|
(par défaut : 0.0.0.0).
|
|
|
|
Utiliser seulement pour le serveur intégré.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[default_encoding] encodage à utiliser si inconnu (par défaut
|
|
|
|
<tt>"utf-8"</tt>).
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[dump_errors] afficher les erreurs dans le +log+.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[environment] environnement courant, par défaut
|
|
|
|
<tt>ENV['RACK_ENV']</tt>, ou
|
|
|
|
<tt>"development"</tt> si absent.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[logging] utiliser le +logger+.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[lock] Place un +lock+ autour de chaque requête, n'exécutant
|
|
|
|
donc qu'une seule requête par processus Ruby.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
Activé si votre application n'est pas +thread-safe+.
|
|
|
|
Désactivé par défaut.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[method_override] utilise la magie de <tt>_method</tt> afin de permettre
|
|
|
|
des formulaires put/delete dans des navigateurs qui ne
|
|
|
|
le permettent pas.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[port] port à écouter. Utiliser seulement pour le serveur
|
|
|
|
intégré.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[prefixed_redirects] si oui ou non <tt>request.script_name</tt> doit être
|
|
|
|
inséré dans les redirections si un chemin non absolu
|
|
|
|
est utilisé. Ainsi, <tt>redirect '/foo'</tt> se
|
|
|
|
comportera comme <tt>redirect to('/foo')</tt>.
|
|
|
|
Désactivé par défaut.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[protection] défini s'il faut activer ou non la protection contre
|
2012-03-03 09:46:20 +00:00
|
|
|
les attaques web. Voir la section protection précédente.
|
2011-09-15 12:18:32 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[public_folder] chemin pour le dossier à partir duquel les fichiers
|
|
|
|
publics sont servis. Utilisé seulement si les fichiers
|
|
|
|
statiques doivent être servis (voir le paramètre
|
|
|
|
<tt>static</tt>). Si non défini, il découle du paramètre
|
|
|
|
<tt>app_file</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[reload_templates] si oui ou non les templates doivent être rechargés
|
|
|
|
entre les requêtes. Activé en mode développement.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[root] chemin pour le dossier racine du projet. Si non défini,
|
|
|
|
il découle du paramètre <tt>app_file</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-06 00:04:22 +00:00
|
|
|
[raise_errors] soulever les erreurs (ce qui arrêtera l'application).
|
2012-03-04 08:33:57 +00:00
|
|
|
Désactivé par défaut sauf lorsque <tt>environment</tt>
|
|
|
|
est défini à <tt>"test"</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[run] si activé, Sinatra s'occupera de démarrer le serveur,
|
|
|
|
ne pas activer si vous utiliser rackup ou autres.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[running] est-ce que le serveur intégré est en marche ?
|
|
|
|
ne changez pas ce paramètre !
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[server] serveur ou liste de serveurs à utiliser pour le serveur
|
|
|
|
intégré.
|
|
|
|
Par défaut ['thin', 'mongrel', 'webrick'], l'ordre
|
|
|
|
indiquant la priorité.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[sessions] active le support des sessions basées sur les cookies, en
|
|
|
|
utilisant <tt>Rack::Session::Cookie</tt>. Reportez-vous
|
|
|
|
à la section 'Utiliser les sessions' pour plus
|
|
|
|
d'informations.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[show_exceptions] affiche la trace de l'erreur dans le navigateur lorsqu'une
|
|
|
|
exception se produit. Désactivé par défaut sauf lorsque
|
2012-03-04 08:33:57 +00:00
|
|
|
<tt>environment</tt> est défini à <tt>"development"</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[static] Si oui ou non Sinatra doit s'occuper de servir les
|
|
|
|
fichiers statiques.
|
|
|
|
Désactivez si vous utilisez un serveur capable de le
|
|
|
|
gérer lui même. Le désactiver augmentera la performance.
|
|
|
|
Activé par défaut pour le style classique, désactivé pour
|
|
|
|
le style modulaire.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2011-09-15 12:18:32 +00:00
|
|
|
[static_cache_control] A définir quand Sinatra rend des fichiers statiques pour
|
|
|
|
ajouter les en-têtes <tt>Cache-Control</tt>. Utilise le
|
|
|
|
helper +cache_control+. Désactivé par défaut.
|
|
|
|
Utiliser un array explicite pour définir des plusieurs
|
|
|
|
valeurs :
|
|
|
|
<tt>set :static_cache_control, [:public, :max_age => 300]</tt>
|
|
|
|
|
2011-09-15 12:22:20 +00:00
|
|
|
[threaded] à définir à +true+ pour indiquer à Thin d'utiliser
|
|
|
|
<tt>EventMachine.defer</tt> pour traiter la requête.
|
2011-09-01 15:32:10 +00:00
|
|
|
|
2012-03-04 08:31:09 +00:00
|
|
|
[views] chemin pour le dossier des vues. Si non défini, il
|
|
|
|
découle du paramètre <tt>app_file</tt>.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-03 09:34:18 +00:00
|
|
|
== Environements
|
|
|
|
|
|
|
|
Il existe trois environnements prédéfinis : <tt>"development"</tt>,
|
|
|
|
<tt>"production"</tt> et <tt>"test"</tt>. Les environements peuvent être
|
|
|
|
sélectionné via la variable d'environnement +RACK_ENV+. Sa valeur par défaut
|
|
|
|
est <tt>"development"</tt>. Dans ce mode, tous les templates sont rechargés à
|
|
|
|
chaque requête. Des handlers spécifiques pour <tt>not_found</tt> et
|
|
|
|
<tt>error</tt> sont installés pour vous permettre d'avoir une pile de trace
|
|
|
|
dans votre navigateur. En mode <tt>"production"</tt> et <tt>"test"</tt> les
|
|
|
|
templates sont mis en cache par défaut.
|
|
|
|
|
|
|
|
Pour exécuter votre application dans un environnement différent, utilisez
|
|
|
|
l'option <tt>-e</tt> de Ruby :
|
|
|
|
|
|
|
|
ruby mon_application.rb -e [ENVIRONMENT]
|
|
|
|
|
|
|
|
Vous pouvez utiliser une des méthodes +development?+, +test?+ et +production?+
|
|
|
|
pour déterminer quel est l'environnement en cours.
|
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Gérer les erreurs
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Les gestionnaires d'erreur s'exécutent dans le même contexte que les routes ou
|
|
|
|
les filtres, ce qui veut dire que vous avez accès (entre autres) aux bons
|
|
|
|
vieux <tt>haml</tt>, <tt>erb</tt>, <tt>halt</tt>, etc.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
=== NotFound
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Quand une exception <tt>Sinatra::NotFound</tt> est soulevée, ou que le code
|
2011-05-02 12:44:49 +00:00
|
|
|
retour est 404, le gestionnaire <tt>not_found</tt> est invoqué :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
not_found do
|
|
|
|
'Pas moyen de trouver ce que vous cherchez'
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
=== Error
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Le gestionnaire +error+ est invoqué à chaque fois qu'une exception est
|
|
|
|
soulevée dans une route ou un filtre. L'objet exception est accessible via la
|
2011-05-02 12:44:49 +00:00
|
|
|
variable Rack <tt>sinatra.error</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
error do
|
|
|
|
'Désolé mais une méchante erreur est survenue - ' + env['sinatra.error'].name
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Erreur sur mesure :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
error MonErreurSurMesure do
|
2011-04-17 10:43:22 +00:00
|
|
|
'Donc il est arrivé ceci...' + env['sinatra.error'].message
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Donc si ceci arrive :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
get '/' do
|
|
|
|
raise MonErreurSurMesure, 'quelque chose de mal'
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Vous obtenez ça :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
Donc il est arrivé ceci... quelque chose de mal
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Alternativement, vous pouvez avoir un gestionnaire d'erreur associé à un code
|
2011-05-02 12:44:49 +00:00
|
|
|
particulier :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
error 403 do
|
|
|
|
'Accès interdit'
|
|
|
|
end
|
|
|
|
|
|
|
|
get '/secret' do
|
|
|
|
403
|
|
|
|
end
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Ou un intervalle :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
error 400..510 do
|
|
|
|
'Boom'
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Sinatra installe pour vous quelques gestionnaires <tt>not_found</tt> et
|
|
|
|
<tt>error</tt> génériques lorsque vous êtes en environnement
|
|
|
|
<tt>development</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
== Les Middlewares Rack
|
|
|
|
|
|
|
|
Sinatra tourne avec Rack[http://rack.rubyforge.org/], une interface standard
|
|
|
|
et minimale pour les web frameworks Ruby. Un des points forts de Rack est le
|
2011-03-06 21:01:52 +00:00
|
|
|
support de ce que l'on appelle des "middlewares" -- composant qui vient se
|
|
|
|
situer entre le serveur et votre application, et dont le but est de
|
|
|
|
visualiser/manipuler la requête/réponse HTTP, et d'offrir diverses
|
|
|
|
fonctionnalités classiques.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
Sinatra permet de construire facilement des middlewares Rack via la méthode de
|
2011-05-02 12:44:49 +00:00
|
|
|
haut niveau +use+ :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
require 'sinatra'
|
|
|
|
require 'mon_middleware_perso'
|
|
|
|
|
|
|
|
use Rack::Lint
|
|
|
|
use MonMiddlewarePerso
|
|
|
|
|
|
|
|
get '/bonjour' do
|
2011-05-02 12:44:49 +00:00
|
|
|
'Bonjour le monde'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
La sémantique de +use+ est identique à celle définie dans le DSL de
|
2010-09-21 06:46:20 +00:00
|
|
|
Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html]
|
2011-03-06 21:01:52 +00:00
|
|
|
(le plus souvent utilisé dans un fichier rackup). Par exemple, la méthode
|
2011-05-02 12:44:49 +00:00
|
|
|
+use+ accepte divers arguments ainsi que des blocs :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
use Rack::Auth::Basic do |login, password|
|
|
|
|
login == 'admin' && password == 'secret'
|
|
|
|
end
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Rack est distribué avec une bonne variété de middlewares standards pour les
|
|
|
|
logs, débuguer, faire du routage URL, de l'authentification, gérer des
|
|
|
|
sessions. Sinatra utilise beaucoup de ces composants automatiquement via la
|
|
|
|
configuration, donc pour ceux-ci vous n'aurez pas à utiliser la méthode +use+.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
== Tester
|
|
|
|
|
|
|
|
Les tests pour Sinatra peuvent être écrit avec n'importe quelle bibliothèque
|
|
|
|
basée sur Rack. {Rack::Test}[http://gitrdoc.com/brynary/rack-test] est
|
2011-05-02 12:44:49 +00:00
|
|
|
recommandé :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
require 'mon_application_sinatra'
|
2011-03-06 21:01:52 +00:00
|
|
|
require 'test/unit'
|
2010-09-21 06:46:20 +00:00
|
|
|
require 'rack/test'
|
|
|
|
|
|
|
|
class MonTest < Test::Unit::TestCase
|
|
|
|
include Rack::Test::Methods
|
|
|
|
|
|
|
|
def app
|
|
|
|
Sinatra::Application
|
|
|
|
end
|
|
|
|
|
|
|
|
def test_ma_racine
|
|
|
|
get '/'
|
2011-05-02 12:44:49 +00:00
|
|
|
assert_equal 'Bonjour le monde !', last_response.body
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def test_avec_des_parametres
|
|
|
|
get '/rencontrer', :name => 'Frank'
|
2011-05-02 12:44:49 +00:00
|
|
|
assert_equal 'Salut Frank !', last_response.body
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def test_avec_rack_env
|
|
|
|
get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
|
2011-05-02 12:44:49 +00:00
|
|
|
assert_equal "Vous utilisez Songbird !", last_response.body
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
== Sinatra::Base - Les Middlewares, Bibliothèques, et Applications Modulaires
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Définir votre application au niveau supérieur fonctionne bien dans le cas des
|
|
|
|
micro-applications mais présente pas mal d'inconvénients pour créer des
|
|
|
|
composants réutilisables sous forme de middlewares Rack, de Rails metal, de
|
|
|
|
simples librairies avec un composant serveur ou même d'extensions Sinatra. Le
|
|
|
|
niveau supérieur suppose une configuration dans le style des micro-applications
|
|
|
|
(une application d'un seul fichier, des répertoires <tt>./public</tt> et
|
|
|
|
<tt>./views</tt>, des logs, une page d'erreur, etc...). C'est là que
|
|
|
|
<tt>Sinatra::Base</tt> prend tout son intérêt :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
class MonApplication < Sinatra::Base
|
|
|
|
set :sessions, true
|
|
|
|
set :foo, 'bar'
|
|
|
|
|
|
|
|
get '/' do
|
2011-05-02 12:44:49 +00:00
|
|
|
'Bonjour le monde !'
|
2010-09-21 06:46:20 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Les méthodes de la classe <tt>Sinatra::Base</tt> sont parfaitement identiques à
|
|
|
|
celles disponibles via le DSL de haut niveau. Il suffit de deux modifications
|
|
|
|
pour transformer la plupart des applications de haut niveau en un composant
|
|
|
|
<tt>Sinatra::Base</tt> :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
* Votre fichier doit charger +sinatra/base+ au lieu de +sinatra+, sinon toutes
|
|
|
|
les méthodes du DSL Sinatra seront importées dans l'espace de nom principal.
|
|
|
|
* Les gestionnaires de routes, la gestion d'erreur, les filtres et les options
|
|
|
|
doivent être placés dans une classe héritant de <tt>Sinatra::Base</tt>.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
<tt>Sinatra::Base</tt> est une page blanche. La plupart des options sont
|
|
|
|
désactivées par défaut, y compris le serveur intégré. Reportez-vous à
|
|
|
|
{Options et Configuration}[http://sinatra.github.com/configuration.html]
|
|
|
|
pour plus d'informations sur les options et leur fonctionnement.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Style modulaire vs. style classique
|
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Contrairement aux idées reçues, il n'y a rien de mal à utiliser le style
|
|
|
|
classique. Si c'est ce qui convient pour votre application, vous n'avez pas
|
|
|
|
aucune raison de passer à une application modulaire.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Le principal inconvénient du style classique sur le style modulaire est que vous
|
|
|
|
ne pouvez avoir qu'une application Ruby par processus Ruby. Si vous pensez en
|
|
|
|
utiliser plus, passez au style modulaire. Et rien ne vous empêche de mixer style
|
|
|
|
classique et style modulaire.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Si vous passez d'un style à l'autre, souvenez-vous des quelques différences
|
|
|
|
mineures en ce qui concerne les paramètres par défaut :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
Paramètre Classique Modulaire
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-05 23:54:55 +00:00
|
|
|
app_file fichier chargeant sinatra fichier héritant de Sinatra::Base
|
|
|
|
run $0 == app_file false
|
|
|
|
logging true false
|
|
|
|
method_override true false
|
|
|
|
inline_templates true false
|
|
|
|
static true false
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
=== Servir une application modulaire
|
|
|
|
|
|
|
|
Il y a deux façons de faire pour démarrer une application modulaire, démarrez
|
|
|
|
avec <tt>run!</tt> :
|
|
|
|
|
|
|
|
# my_app.rb
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
class MyApp < Sinatra::Base
|
|
|
|
# ... code de l'application ici ...
|
|
|
|
|
|
|
|
# démarre le serveur si ce fichier est directement exécuté
|
|
|
|
run! if app_file == $0
|
|
|
|
end
|
|
|
|
|
|
|
|
Démarrez ensuite avec :
|
|
|
|
|
|
|
|
ruby my_app.rb
|
|
|
|
|
|
|
|
Ou alors avec un fichier <tt>config.ru</tt>, qui permet d'utiliser n'importe
|
|
|
|
quel gestionnaire Rack :
|
|
|
|
|
|
|
|
# config.ru
|
2011-06-01 09:52:09 +00:00
|
|
|
require './my_app'
|
2011-03-06 21:01:52 +00:00
|
|
|
run MyApp
|
|
|
|
|
|
|
|
Exécutez :
|
|
|
|
|
|
|
|
rackup -p 4567
|
|
|
|
|
|
|
|
=== Utiliser une application de style classique avec un fichier config.ru
|
|
|
|
|
|
|
|
Ecrivez votre application :
|
|
|
|
|
|
|
|
# app.rb
|
|
|
|
require 'sinatra'
|
|
|
|
|
|
|
|
get '/' do
|
2011-05-02 12:44:49 +00:00
|
|
|
'Bonjour le monde !'
|
2011-03-06 21:01:52 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
Et un fichier <tt>config.ru</tt> correspondant :
|
|
|
|
|
2011-06-01 09:52:09 +00:00
|
|
|
require './app'
|
2011-03-06 21:01:52 +00:00
|
|
|
run Sinatra::Application
|
|
|
|
|
|
|
|
=== Quand utiliser un fichier config.ru ?
|
|
|
|
|
|
|
|
Quelques cas où vous devriez utiliser un fichier <tt>config.ru</tt> :
|
|
|
|
|
|
|
|
* Vous souhaitez déployer avec un autre gestionnaire Rack (Passenger, Unicorn,
|
|
|
|
Heroku, ...).
|
|
|
|
* Vous souhaitez utiliser plus d'une sous-classe de <tt>Sinatra::Base</tt>.
|
|
|
|
* Vous voulez utiliser Sinatra comme un +middleware+, non en tant que
|
|
|
|
+endpoint+.
|
|
|
|
|
|
|
|
<b>Il n'est pas nécessaire de passer par un fichier <tt>config.ru</tt> pour la
|
|
|
|
seule raison que vous êtes passé au style modulaire, et vous n'avez pas besoin
|
|
|
|
de passer au style modulaire pour utiliser un fichier <tt>config.ru</tt>.</b>
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
=== Utiliser Sinatra comme Middleware
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Non seulement Sinatra peut utiliser d'autres middlewares Rack, il peut
|
|
|
|
également être à son tour utilisé au-dessus de n'importe quel +endpoint+ Rack
|
|
|
|
en tant que middleware. Ce +endpoint+ peut très bien être une autre
|
|
|
|
application Sinatra, ou n'importe quelle application basée sur Rack
|
2011-05-02 12:44:49 +00:00
|
|
|
(Rails/Ramaze/Camping/...) :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
class EcranDeConnexion < Sinatra::Base
|
2010-11-07 08:49:23 +00:00
|
|
|
enable :sessions
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
get('/connexion') { haml :connexion }
|
|
|
|
|
|
|
|
post('/connexion') do
|
2011-05-03 21:27:51 +00:00
|
|
|
if params[:nom] = 'admin' && params[:motdepasse] = 'admin'
|
2010-10-06 22:11:36 +00:00
|
|
|
session['nom_utilisateur'] = params[:nom]
|
|
|
|
else
|
|
|
|
redirect '/connexion'
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
class MonApp < Sinatra::Base
|
|
|
|
# le middleware sera appelé avant les filtres
|
|
|
|
use EcranDeConnexion
|
|
|
|
|
|
|
|
before do
|
|
|
|
unless session['nom_utilisateur']
|
|
|
|
halt "Accès refusé, merci de vous <a href='/connexion'>connecter</a>."
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
get('/') { "Bonjour #{session['nom_utilisateur']}." }
|
|
|
|
end
|
|
|
|
|
2011-04-05 21:20:17 +00:00
|
|
|
=== Création dynamique d'applications
|
|
|
|
|
|
|
|
Il se peut que vous ayez besoin de créer une nouvelle application à l'exécution
|
|
|
|
sans avoir à les assigner à une constante, vous pouvez le faire grâce à
|
2011-05-02 12:44:49 +00:00
|
|
|
<tt>Sinatra.new</tt> :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
mon_app = Sinatra.new { get('/') { "salut" } }
|
|
|
|
mon_app.run!
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
L'application dont elle hérite peut être passé en argument optionnel :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
2011-07-01 23:55:08 +00:00
|
|
|
# config.ru
|
2011-04-05 21:20:17 +00:00
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
controleur = Sinatra.new do
|
|
|
|
enable :logging
|
|
|
|
helpers MyHelpers
|
|
|
|
end
|
|
|
|
|
|
|
|
map('/a') do
|
|
|
|
run Sinatra.new(controleur) { get('/') { 'a' } }
|
|
|
|
end
|
|
|
|
|
|
|
|
map('/b') do
|
|
|
|
run Sinatra.new(controleur) { get('/') { 'b' } }
|
|
|
|
end
|
|
|
|
|
|
|
|
C'est notamment utile pour tester des extensions à Sinatra ou bien pour
|
|
|
|
utiliser Sinatra dans votre propre bibliothèque.
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Cela permet également d'utiliser très facilement Sinatra comme middleware :
|
2011-04-05 21:20:17 +00:00
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
use Sinatra do
|
|
|
|
get('/') { ... }
|
|
|
|
end
|
|
|
|
|
|
|
|
run RailsProject::Application
|
|
|
|
|
2010-10-06 22:11:36 +00:00
|
|
|
== Contextes et Binding
|
|
|
|
|
|
|
|
Le contexte dans lequel vous êtes détermine les méthodes et variables
|
|
|
|
disponibles.
|
|
|
|
|
|
|
|
=== Contexte de l'application/classe
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Toute application Sinatra correspond à une sous-classe de <tt>Sinatra::Base</tt>.
|
|
|
|
Si vous utilisez le DSL haut niveau (<tt>require 'sinatra'</tt>), alors cette
|
|
|
|
classe est <tt>Sinatra::Application</tt>, sinon il s'agit de la sous-classe que
|
|
|
|
vous avez définie. Dans le contexte de la classe, vous avez accès aux méthodes
|
2011-05-02 12:44:49 +00:00
|
|
|
telles que +get+ ou +before+, mais vous n'avez pas accès aux objets +request+
|
|
|
|
ou +session+ car c'est la même classe d'application qui traitera toutes les
|
2011-03-06 21:01:52 +00:00
|
|
|
requêtes.
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Les options définies au moyen de +set+ deviennent des méthodes de classe :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2010-11-10 19:15:51 +00:00
|
|
|
class MonApp < Sinatra::Base
|
2011-05-02 12:44:49 +00:00
|
|
|
# Eh, je suis dans le contexte de l'application !
|
2010-10-06 22:11:36 +00:00
|
|
|
set :foo, 42
|
|
|
|
foo # => 42
|
|
|
|
|
|
|
|
get '/foo' do
|
2011-05-02 12:44:49 +00:00
|
|
|
# Eh, je ne suis plus dans le contexte de l'application !
|
2010-10-06 22:11:36 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Vous avez le binding du contexte de l'application dans :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
* Le corps de la classe d'application
|
|
|
|
* Les méthodes définies par les extensions
|
2011-05-02 12:44:49 +00:00
|
|
|
* Le bloc passé à +helpers+
|
|
|
|
* Les procs/blocs utilisés comme argument pour +set+
|
2011-04-05 21:20:17 +00:00
|
|
|
* Le bloc passé à <tt>Sinatra.new</tt>
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-03 21:27:51 +00:00
|
|
|
Vous pouvez atteindre ce contexte (donc la classe) de la façon suivante :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
* Via l'objet passé dans les blocs +configure+ (<tt>configure { |c| ... }</tt>)
|
|
|
|
* En utilisant +settings+ dans le contexte de la requête
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
=== Contexte de la requête/instance
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Pour tout traitement d'une requête, une nouvelle instance de votre classe
|
|
|
|
d'application est créée et tous vos gestionnaires sont exécutés dans ce
|
2011-05-02 12:44:49 +00:00
|
|
|
contexte. Dans ce dernier, vous pouvez accéder aux objets +request+ et
|
|
|
|
+session+ et faire appel aux fonctions de rendu telles que +erb+ ou +haml+.
|
2011-03-06 21:01:52 +00:00
|
|
|
Vous pouvez accéder au contexte de l'application depuis le contexte de la
|
2011-05-02 12:44:49 +00:00
|
|
|
requête au moyen de +settings+ :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2010-11-10 19:15:51 +00:00
|
|
|
class MonApp < Sinatra::Base
|
2011-05-02 12:44:49 +00:00
|
|
|
# Eh, je suis dans le contexte de l'application !
|
2010-10-06 22:11:36 +00:00
|
|
|
get '/ajouter_route/:nom' do
|
|
|
|
# Contexte de la requête pour '/ajouter_route/:nom'
|
|
|
|
@value = 42
|
|
|
|
|
|
|
|
settings.get("/#{params[:nom]}") do
|
|
|
|
# Contexte de la requête pour "/#{params[:nom]}"
|
|
|
|
@value # => nil (on est pas au sein de la même requête)
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
"Route ajoutée !"
|
2010-10-06 22:11:36 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Vous avez le binding du contexte de la requête dans :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
* les blocs get/head/post/put/delete/options
|
2010-10-06 22:11:36 +00:00
|
|
|
* les filtres before/after
|
2011-05-02 12:44:49 +00:00
|
|
|
* les méthodes utilitaires (définies au moyen de +helpers+)
|
2010-10-06 22:11:36 +00:00
|
|
|
* les vues/templates
|
|
|
|
|
|
|
|
=== Le contexte de délégation
|
|
|
|
|
|
|
|
Le contexte de délégation se contente de transmettre les appels de méthodes au
|
2011-03-06 21:01:52 +00:00
|
|
|
contexte de classe. Toutefois, il ne se comporte pas à 100% comme le contexte
|
2011-05-03 21:27:51 +00:00
|
|
|
de classe car vous n'avez pas le binding de la classe : seules les méthodes
|
2011-03-06 21:01:52 +00:00
|
|
|
spécifiquement déclarées pour délégation sont disponibles et il n'est pas
|
|
|
|
possible de partager des variables/états avec le contexte de classe
|
2011-05-03 21:27:51 +00:00
|
|
|
(comprenez : +self+ n'est pas le même). Vous pouvez ajouter des délégation de
|
2011-03-06 21:01:52 +00:00
|
|
|
méthodes en appelant <tt>Sinatra::Delegator.delegate :method_name</tt>.
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Vous avez le binding du contexte de délégation dans :
|
2010-10-06 22:11:36 +00:00
|
|
|
|
|
|
|
* Le binding de haut niveau, si vous avez utilisé <tt>require "sinatra"</tt>
|
2011-05-02 12:44:49 +00:00
|
|
|
* Un objet qui inclut le module +Sinatra::Delegator+
|
2010-10-06 22:11:36 +00:00
|
|
|
|
2012-03-06 00:21:22 +00:00
|
|
|
Jetez un oeil pour vous faire une idée : voici le
|
|
|
|
{mixin Sinatra::Delegator}[https://github.com/sinatra/sinatra/blob/ca06364/lib/sinatra/base.rb#L1609-1633]
|
|
|
|
qui {étend l'objet principal}[https://github.com/sinatra/sinatra/blob/ca06364/lib/sinatra/main.rb#L28-30].
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
== Ligne de commande
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Les applications en Sinatra peuvent être lancées directement :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
ruby mon_application.rb [-h] [-x] [-e ENVIRONNEMENT] [-p PORT] [-o HOTE] [-s SERVEUR]
|
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
Les options sont :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
|
|
|
-h # aide
|
|
|
|
-p # déclare le port (4567 par défaut)
|
|
|
|
-o # déclare l'hôte (0.0.0.0 par défaut)
|
|
|
|
-e # déclare l'environnement (+development+ par défaut)
|
|
|
|
-s # déclare le serveur/gestionnaire à utiliser (thin par défaut)
|
|
|
|
-x # active le mutex lock (off par défaut)
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
== Configuration nécessaire
|
|
|
|
|
|
|
|
Les versions suivantes de Ruby sont officiellement supportées :
|
|
|
|
|
|
|
|
[ Ruby 1.8.7 ]
|
2012-03-03 11:19:15 +00:00
|
|
|
1.8.7 est complètement supporté, toutefois si rien ne vous en empêche, nous
|
|
|
|
vous recommandons de passer à 1.9.2 ou bien de passer à JRuby ou Rubinius. Le
|
|
|
|
support de Ruby 1.8.7 ne sera pas supprimé avant la sortie de Sinatra 2.0 et
|
|
|
|
de Ruby 2.0, à moins qu'un improbable Ruby 1.8.8 apparaisse. Et même dans ce
|
|
|
|
cas, nous pourrions continuer à le supporter. <b>Ruby 1.8.6 n'est plus
|
|
|
|
supporté.</b> Si vous souhaitez utiliser la version 1.8.6, vous devez revenir
|
|
|
|
à Sinatra 1.2 qui continuera à recevoir des corrections de bugs tant que
|
|
|
|
Sinatra 1.4.0 ne sera pas livré.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
[ Ruby 1.9.2 ]
|
2012-03-03 11:19:15 +00:00
|
|
|
1.9.2 est totalement supporté et recommandé. Notez que Radius et Markaby ne
|
|
|
|
sont actuellement pas compatible avec 1.9. N'utilisez pas 1.9.2p0 car il
|
|
|
|
provoque des erreurs de segmentation à l'exécution de Sinatra. Son support
|
|
|
|
continuera au minimum jusqu'à la sortie de Ruby 1.9.4/2.0 et le support de la
|
|
|
|
dernière version 1.9 se poursuivra aussi longtemps que la core team de Ruby la
|
|
|
|
supportera.
|
|
|
|
|
|
|
|
[ Ruby 1.9.3 ]
|
|
|
|
1.9.3 est totalement supporté. Nous recommandons d'attendre qu'un premier
|
|
|
|
niveau de patch sorte (pour l'instant on en est à p0) avant de l'employer en
|
|
|
|
production. Nous vous rappelons que passer à 1.9.3 depuis une version
|
|
|
|
précédente annulera toutes les sessions.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
[ Rubinius ]
|
2012-03-03 11:19:15 +00:00
|
|
|
Rubinius est officiellement supporté (Rubinius >= 1.2.4), tout fonctionne,
|
|
|
|
y compris tous les langages de template. La version 2.0 à venir est
|
|
|
|
également supportée.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
[ JRuby ]
|
2012-03-03 11:19:15 +00:00
|
|
|
JRuby est officiellement supporté (JRuby >= 1.6.5). Aucune anomalie avec
|
2011-03-06 21:01:52 +00:00
|
|
|
des bibliothèques de templates tierces ne sont connues. Toutefois, si vous
|
|
|
|
choisissez JRuby, alors tournez vous vers des gestionnaires Rack JRuby car
|
2011-04-05 21:20:17 +00:00
|
|
|
le serveur Thin n'est pas complètement supporté par JRuby. Le support des
|
|
|
|
extensions C dans JRuby est encore expérimental, ce qui n'affecte que
|
2012-03-03 11:19:15 +00:00
|
|
|
RDiscount, Redcarpet and RedCloth pour l'instant.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
|
|
|
Nous gardons également un oeil sur les versions Ruby à venir.
|
|
|
|
|
|
|
|
Les implémentations Ruby suivantes ne sont pas officiellement supportées mais
|
2012-03-03 11:19:15 +00:00
|
|
|
sont malgré tout connues pour permettre de faire fonctionner Sinatra :
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-03 11:19:15 +00:00
|
|
|
* Versions plus anciennes de JRuby et Rubinius
|
|
|
|
* Ruby Enterprise Edition
|
2011-04-05 21:20:17 +00:00
|
|
|
* MacRuby, Maglev, IronRuby
|
2012-03-03 11:19:15 +00:00
|
|
|
* Ruby 1.9.0 et 1.9.1 (mais nous déconseillons leur utilisation)
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-03 11:19:15 +00:00
|
|
|
Le fait de ne pas être officiellement supporté signifie que si quelque chose
|
|
|
|
ne fonctionne pas uniquement sur cette plateforme alors c'est un problème de la
|
|
|
|
plateforme et pas un bug de Sinatra.
|
2011-03-06 21:01:52 +00:00
|
|
|
|
2012-03-03 11:19:15 +00:00
|
|
|
Nous lançons également notre intégration continue (CI) avec ruby-head (la
|
|
|
|
future 2.0.0) et la branche 1.9.4, mais étant donné les évolutions continuelles,
|
|
|
|
nous ne pouvont rien garantir, si ce n'est que les versions 1.9.4p0 et 2.0.0p0
|
|
|
|
seront supportées.
|
2011-04-05 21:20:17 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Sinatra devrait fonctionner sur n'importe quel système d'exploitation
|
|
|
|
supportant l'implémentation Ruby choisie.
|
|
|
|
|
2012-03-03 11:19:15 +00:00
|
|
|
Il n'est pas possible d'utiliser Sinatra sur Cardinal, SmallRuby, Blueuby ou
|
2012-03-06 00:04:22 +00:00
|
|
|
toute version de Ruby antérieure à 1.8.7 à l'heure actuelle.
|
2012-03-03 11:19:15 +00:00
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Essuyer les plâtres
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
Si vous voulez utiliser la toute dernière version de Sinatra, n'ayez pas peur
|
|
|
|
de faire tourner votre application sur la branche master, cela devrait être
|
|
|
|
stable.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2012-03-06 00:04:22 +00:00
|
|
|
Nous publions également une gem de +prerelease+ de temps en temps que vous
|
2011-05-02 12:44:49 +00:00
|
|
|
pouvez installer comme suit :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
gem install sinatra --pre
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-05-02 12:44:49 +00:00
|
|
|
afin d'avoir les toutes dernières fonctionnalités.
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Avec Bundler
|
|
|
|
|
|
|
|
Si vous voulez faire tourner votre application avec le tout dernier
|
|
|
|
Sinatra, {Bundler}[http://gembundler.com/] est recommandé.
|
|
|
|
|
|
|
|
Tout d'abord, installer bundler si vous ne l'avez pas :
|
|
|
|
|
|
|
|
gem install bundler
|
|
|
|
|
|
|
|
Ensuite, dans le dossier de votre projet, créez un fichier +Gemfile+ :
|
|
|
|
|
|
|
|
source :rubygems
|
|
|
|
gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
|
|
|
|
|
|
|
|
# autres dépendances
|
|
|
|
gem 'haml' # par exemple, si vous utilisez haml
|
|
|
|
gem 'activerecord', '~> 3.0' # peut-être que vous avez également besoin
|
|
|
|
# de ActiveRecord 3.x
|
|
|
|
|
|
|
|
Notez que vous aurez à lister toutes les dépendances de votre application dans
|
|
|
|
ce fichier. Les dépendances directes de Sinatra (Rack et Tilt) seront
|
|
|
|
automatiquement téléchargées et ajoutées par Bundler.
|
|
|
|
|
|
|
|
Maintenant, vous pouvez faire tourner votre application de la façon suivante :
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
bundle exec ruby myapp.rb
|
2010-09-21 06:46:20 +00:00
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Faites le vous-même
|
|
|
|
|
|
|
|
Créez un clone local et démarrez votre application avec le dossier
|
|
|
|
<tt>sinatra/lib</tt> dans le <tt>$LOAD_PATH</tt> :
|
|
|
|
|
|
|
|
cd myapp
|
|
|
|
git clone git://github.com/sinatra/sinatra.git
|
|
|
|
ruby -Isinatra/lib myapp.rb
|
|
|
|
|
|
|
|
A l'avenir, pour mettre à jour le code source de Sinatra :
|
|
|
|
|
|
|
|
cd myapp/sinatra
|
2010-09-21 06:46:20 +00:00
|
|
|
git pull
|
|
|
|
|
2011-03-06 21:01:52 +00:00
|
|
|
=== Installez globalement
|
|
|
|
|
|
|
|
Vous pouvez construire la gem vous-même :
|
|
|
|
|
|
|
|
git clone git://github.com/sinatra/sinatra.git
|
|
|
|
cd sinatra
|
|
|
|
rake sinatra.gemspec
|
|
|
|
rake install
|
|
|
|
|
|
|
|
Si vous installez les gems en tant que +root+, la dernière étape sera :
|
|
|
|
|
|
|
|
sudo rake install
|
|
|
|
|
2011-03-09 08:32:03 +00:00
|
|
|
== Versions
|
|
|
|
|
|
|
|
Sinatra se conforme aux {versions sémantiques}[http://semver.org/], aussi bien
|
|
|
|
SemVer que SemVerTag.
|
|
|
|
|
2010-09-21 06:46:20 +00:00
|
|
|
== Mais encore
|
|
|
|
|
|
|
|
* {Site internet}[http://www.sinatrarb.com/] - Plus de documentation,
|
|
|
|
de news, et des liens vers d'autres ressources.
|
2011-03-06 21:01:52 +00:00
|
|
|
* {Contribuer}[http://www.sinatrarb.com/contributing] - Vous avez trouvé un
|
2011-05-02 12:44:49 +00:00
|
|
|
bug ? Besoin d'aide ? Vous avez un patch ?
|
2010-10-06 22:11:36 +00:00
|
|
|
* {Suivi des problèmes}[http://github.com/sinatra/sinatra/issues]
|
2010-09-21 06:46:20 +00:00
|
|
|
* {Twitter}[http://twitter.com/sinatra]
|
|
|
|
* {Mailing List}[http://groups.google.com/group/sinatrarb/topics]
|
2011-05-03 21:27:51 +00:00
|
|
|
* {IRC : #sinatra}[irc://chat.freenode.net/#sinatra] sur http://freenode.net
|
|
|
|
* {IRC : #sinatra}[irc://chat.freenode.net/#sinatra] on http://freenode.net
|
|
|
|
* {Sinatra Book}[http://sinatra-book.gittr.com] Tutoriels et recettes
|
2011-10-14 22:12:40 +00:00
|
|
|
* {Sinatra Recipes}[http://recipes.sinatrarb.com/] Recettes contribuées
|
2011-05-03 21:27:51 +00:00
|
|
|
par la communauté
|
|
|
|
* Documentation API de la {dernière version}[http://rubydoc.info/gems/sinatra]
|
|
|
|
ou du {HEAD courant}[http://rubydoc.info/github/sinatra/sinatra] sur
|
2011-09-15 12:28:49 +00:00
|
|
|
http://rubydoc.info
|
2011-10-28 12:15:59 +00:00
|
|
|
* {CI server}[http://ci.rkh.im/view/Sinatra/]
|