Para comprender correctamente todo lo que hablaremos en esta serie, es conveniente tener un conocimiento básico sobre el lenguaje de Ruby. Podrás conseguir toda la información desees aquí
Filtros
En Sinatra existen dos tipos de filtros con los que se puede interactuar los dos se utilizan de la misma forma y su función es utilizada para modificar una petición recibida ya sea antes de ser procesada o posterior al procesamiento. Los filtros tienen la capacidad de realizar un tender de una vista, realizar una petición, responder con objetos, entre otros…
Filtros antes del procesamiento
Estos filtros son llamados en inglés “Before filter” y son aplicados justo cuando se recibe una petición, es decir: si quisiéramos realizar una comprobación de un usuario para ver si el mismo está en sesión en nuestra aplicación se puede realizar un método que compruebe esto y no permita al usuario realizar la petición que intentaba de no estarlo. Este tipo de filtros es sumamente útil para realizar este tipo de validaciones de seguridad y de comprobación de rol de usuarios.
En el siguiente ejemplo se creará un “Before filter” el cual le dará un valor a una variable que será mostrada en pantalla.
require 'sinatra' before do @before_value = 'Hola, Mundo!' end get '/' do "El valor de la variable será: #{@before_value}" end123456789 require'sinatra' before do @before_value='Hola, Mundo!'end get'/'do "El valor de la variable será: #{@before_value}"end
Al ingresar al URL se aprecia el mensaje completo El valor de la variable será: Hola, Mundo! indicando que el filtro funcionó.
Filtros posterior al procesamiento
De la misma manera que los “Before filters” tenemos los “After filter”, llamados en español posteriores al procesamiento. Este filtro a diferencia del “Before filter” no puede interrumpir una petición de procesamiento ya que los mismos se ejecutan posterior a la misma. Hay que tener cuidado de como utilizamos este filtro ya que si lo estamos empleando para ejecutar una operación costosa en tiempo este tiempo se añadirá al tiempo total de la petición y puede que afecte al usuario.
Para el ejemplo de “After filter” utilizaremos el mismo código anterior pero agregaremos el filtro y observaremos la salida que se muestra en el terminal.
require 'sinatra' before do @before_value = 'Hola, Mundo!' end get '/' do "El valor de la variable será: #{@before_value}" end after do puts "Llamando al After filter." end12345678910111213 require'sinatra' before do @before_value='Hola, Mundo!'end get'/'do "El valor de la variable será: #{@before_value}"end after do puts"Llamando al After filter."end
Podemos observar que por cada una de las peticiones realizadas al servidor se ejecuta el “after filter”.
ruby server.rb Puma 2.6.0 starting... * Min threads: 0, max threads: 16 * Environment: development * Listening on tcp://localhost:4567 == Sinatra/1.4.3 has taken the stage on 4567 for development with backup from Puma After filter called to perform some task. ::1 - - [13/Nov/2013 23:59:43] "GET / HTTP/1.1" 200 32 0.0040 Llamando al After filter. ::1 - - [13/Nov/2013 23:59:43] "GET /favicon.ico HTTP/1.1" 404 448 0.001012345678910 ruby serverrbPuma2.6.0starting*Min threads:0,max threads:16*Environment:development*Listening on tcp://localhost:4567==Sinatra/1.4.3has taken the stage on4567fordevelopment with backup from PumaAfter filter called toperform some task::1--[13/Nov/201323:59:43]"GET / HTTP/1.1"200320.0040Llamando al After filter::1--[13/Nov/201323:59:43]"GET /favicon.ico HTTP/1.1"4044480.0010
Manejo de Errores
El manejo de errores es algo muy común en el desarrollo de software; no importa lo que hagamos las aplicaciones siempre tendrán errores y es por esto que de una u otra manera debemos ser capaces de manejar los errores que se produzcan en nuestra aplicación, ya sean por culpa de un usuario o por un fallo en nuestros servidores. Por suerte, para el manejo de errores en aplicaciones web tenemos un estándar al cual apegarnos; el mismo nos indica que código de error debemos servir. Por ejemplo: los códigos para indicar respuestas exitosas de una petición se encuentran entre las 200-299 pero para dar errores de servidor se encuentran entre 500-599.
En Sinatra existen dos envoltorios para los errores más comunes que son el error 404 (Not Found) y el 500 (Internal Server Error). Estos envoltorios “wrappers” funcionan de la misma manera que los filtros.
Not found
El manejo de errores de tipo 404 Not Found se activa cuando la petición a una ruta de la aplicación no se encontró y por esta razón salta esta operación. Debemos tener siempre encuenta el orden en el que se encuentren las rutas. En sinatra el error 404 está definido por el bloque not_found.
12345678910111213 require'sinatra' before do content_type:txtend not_found do "Whoops! You requested a route that wasn't available."end get'/'do "El valor de la variable será"end
La respuesta obtenida siempre será por el not_found y con un mensaje similar a este del lado del servidor ::1 - - [14/Nov/2013 01:21:36] "GET /asd HTTP/1.1" 404 52 0.0027
El cliente verá el mensaje que tiene el bloque not_found:
12 curl--request GET http://localhost:4567/asdWhoops!You requestedaroute that wasn'tavailable
Internal Server Error
El error 500 Internal Server Error es la representación de cualquier error que pueda ocurrir cuando estamos procesando una petición en el servidor. En Sinatra está definida por el bloque error.
Para el bloque error basta con agregarlo a las rutas
12345678910111213 require'sinatra' before do content_type:txtend configure do set:show_exceptions,falseend error do "Y U NO WORK?"end
Conclusión
En este quinto capítulo, hemos aprendido a utilizar de manera muy básica los filtros para realizar verificaciones en las peticiones; como también a manejar los errores más comunes utilizando los envoltorios que nos proporciona Sinatra para esta tarea. Si te surge algún tipo de duda no te detengas y déjanos un comentario, que gustosamente lo responderemos.
¡Hasta el próximo capítulo!
Puzzle Bobble
Karate Blazers
Puzzle De Bloques
Magical Cat Adventure