def Tenako.blog () end

Si queremos utilizar el gem (o es “la” gem, no tengo muy claro el genero) en rails 2.1.0 nos vamos a encontrar con lo siguientes problemas tras haberlo instalado:

Primer problema,cuando vamos a generar nuestro sistema de login.La extension de las plantillas nos causa el primer problemilla:

madtrick$ ruby script/generate login account
      create  lib/login_system.rb
      create  app/controllers/account_controller.rb
      create  test/functional/account_controller_test.rb
      create  app/helpers/account_helper.rb
      create  app/views/layouts/scaffold.rhtml
No such file or directory - /opt/local/lib/ruby/gems/1.8/gems/rails-2.1.0/ 
lib/rails_generator/generators/components/scaffold/templates/layout.rhtml

El error deriva de que el script que genera el login sigue considerando que las plantillas tienen extension .rhtml, cuando eso ya no es asi.Ahora las plantillas utilizan la extension .html.erb

Por lo tanto para solucionar este problema lo que debemos de hacer es modificar la extension del fichero solicitado en el generador , login_generator.rb en este caso.

En mi caso el fichero login_generator.rb se encuentra en /opt/local/lib/ruby/gems/1.8/gems/login_generator-1.2.2 en otros sistemas puede que sea /usr/local/lib/ruby/gems/1.8/gems/login_generator-1.2.2 o /ruby/local/lib/ruby/gems/1.8/gems/login_generator-1.2.2

Pasaremos de:

17

m.template "scaffold:layout.rhtml", "app/views/layouts/scaffold.rhtml"

A:

17

m.template "scaffold:layout.html.erb", "app/views/layouts/scaffold.rhtml"

Si ahora volvemos a intentar generar el sistema de login no tendremos ningun problema:

madtrick$ ruby script/generate login account
   identical  lib/login_system.rb
   identical  app/controllers/account_controller.rb
   identical  test/functional/account_controller_test.rb
   identical  app/helpers/account_helper.rb
overwrite app/views/layouts/scaffold.rhtml? \ 
 (enter "h" for help) [Ynaqdh] Y
       force  app/views/layouts/scaffold.rhtml
      create  public/stylesheets/scaffold.css
      create  app/views/account
      create  app/views/account/welcome.rhtml
      create  app/views/account/login.rhtml
      create  app/views/account/logout.rhtml
      create  app/views/account/signup.rhtml
      create  README_LOGIN

Segundo problema.Tras solventar lo anterior, estamos ansiosos por probar nuestro sistema de login asi que vamos a nuestro navegador y tecleamos: http://localhost:3000/account/login

En la anterior direccion asumimos lo siguiente:

• Que el controlador que hemos creado para gestionar las funciones de login tiene por nombre AccountController
• Que tenemos una ruta en routes.rb que funciona para esta peticion

Si probamos esto una bonita pantalla de error nos dara la bienvenida:

ArgumentError in AccountController#login
 
wrong number of arguments (0 for 1)

Bien, para solucionar esto debemos de modificar todos los @request.method que nos encontremos en nuestro controlador por @request.request_method para evitar colisiones con la palabra reservada de ruby method

Tras solucionar esto volvemos a probar nuestro sistema de login, pero un vez mas nos la dan con queso:

Segundo problema,

 NoMethodError in AccountController#login
 
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.request_method

Bien, bien.Veamos que pasa aqui.Como podemos observar el mensaje de error nos dice que el error ocurrio al tratar de evaluar nil.request_method.Pero oiga, como que nil!! Si yo estoy viendo @request.request_method.

Lo que pasa aqui es que en esta version de Rails, @request (al igual que @params, @session, @flash, @cookies, @headers, @response) ha quedado en desuso en favor de los “accessor methods” que tienen el mismo nombre que las variables pero sin la arroba.Es decir donde tenemos @request.request_method pasamos a tener request.request_method y asi sucesivamente.

Probamos los cambios y nos encontramos con el tercer problema:

 NoMethodError in Account#login
 
Showing account/login.rhtml where line #1 raised:
 
undefined method `start_form_tag' for #<ActionView::Base:0x35a61dc>

login.rhtml luce de la siguiente forma:

<%%= start_form_tag :action=> "login" %>
...
<%%= end_form_tag %>

start_form_tag, tambien esta en desuso, en su lugar debemos de utilizar form_tag.De esta forma login.rhtml nos queda de la siguiente forma:

<% form_tag '/account/login' do  %>
...
<% end %>

Ahora por lo menos podemos probar nuestro login.Lo probamos y tras hacer click en el boton de login,nos encontramos con el cuarto error,

 NoMethodError in AccountController#login
 
undefined method `find_first' for #<Class:0x365c8b0>

find_first es otro de los metodos en desuso.Debemos de cambiarlo por find, con el simbolo :first como primer parametro y la opcion :conditions con la condicion que teniamos en find_first.

Es decir, pasamos de:

find_first(["login = ? AND password = ?", login, sha1(pass)])

A:

find(:first,:conditions=>["login = ? AND password = ?", login, sha1(pass)])

Si volvemos a probar, adivinad que pasa….si, otro error.Por el quinto vamos,otra vez por elementos en desuso.En este caso se trata de la variable @session residente en el fichero login_system.rb.Cambiamos esta y las demas variables existentes en dicho fichero a sus “accesor methods” , guardamos y volvemos a probar… e-voilà!!

Funciona!!

Espero que todo este rollo le sea de ayuda a alguien : )

Hay varias formas para indicar la restriccion que implica una clave foranea en nuestras tablas cuando estamos utilizando las migraciones para definir dichas tablas.

La primera y mas “tosca” consiste en indicar a pelo dicha restriccion:

class CreateOrder < ActiveRecord::Migration
   def self.up
      t.string :name
      t.integer :user_id
 
      execute "alter table table add constraint fk_table_user \ 
         foreign key (user_id) references users (id)"
 
   end
 
   ...
 
end

Pero tambien podemos aprovechar algun plugin para facilitarnos el trabajo.Es aqui donde entra en juego este plugin que descubri hoy.

• Redhillonrails_core

Con este plugin podemos rehacer lo anterior de la siguiente forma:

class CreateOrder < ActiveRecord::Migration
   def self.up
      t.string :name
      t.integer :user_id
 
      t.foreign_key :users,:user_id,:id
 
   end
 
   ...
 
end

Bastante mejor, no?.Este plugin tiene disponible adaptadores para mysql y postgresql.

Aqui teneis los otros plugins que tienen disponibles.

Una de las cosas que mas me gustan de Ruby es su dinamismo y la posibilidad de “abrir” las clases y modulos para añadir o redefinir metodos totalmente dinamicamente y en tiempo de ejecucion.

Esta funcionalidad junto con la posibilidad de saber cuando un modulo ha sido incluido en una clase nos permite añadir funcionalidad a las clases que incluyen el modulo sin que estan tengan que percibirlo.

Un ejemplo:

class Module
  def included(base)
    p "Included module " + name
 
    without = "test_method_#{name}_without_filters".to_sym
    with ="test_method_#{name}_with_filters".to_sym
    base.class_eval do
      alias_method without, :test_method
      alias_method :test_method, with
    end
 
  end
end

Lo que he hecho es redefinir el metodo included para que todos los modulos indiquen que ha sido incluidos y que hagan un alias sobre el metodo “test_method“.

Hay que tener en cuenta que alias_method no sobreescribe el metodo original, sino que hace una guarda una referencia a este, de forma que aun pueda ser invocado.

module A
 
  def test_method_A_with_filters
    p "Doing something really important in module A"
    test_method_A_without_filters
  end
 
end
 
module B
 
  def test_method_B_with_filters
    p "Doing something really important in module B"
    test_method_B_without_filters
  end
 
end
 
 
class Test
 
  def test_method
      p "Inside method of class A"
 
      p "Backtrace:"
      caller.each do |text| p text end
      return
  end
 
  include A
  include B
end

Creamos los modulos, la clase e incluimos los primeros en dicha clase.Hasta aqui nada nuevo bajo el sol.

Probemos entonces el codigo en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test30"
"Included module A"
"Included module B"
=> true
 
irb(main):002:0> Test.new.test_method
"Doing something really important in module B"
"Doing something really important in module A"
"Inside method of class A"
 
"Backtrace:"
"./test30.rb:14:in `test_method_B_without_filters'"
"./test30.rb:32:in `test_method'"
"(irb):2:in `irb_binding'"
"/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'"
":0"
=> nil

Si hechamos un vistazo a la salida generada en irb,

irb(main):001:0> require "test30"
"Included module A"
"Included module B"
=> true

Los modulos se incluyen en la clase en el orden deseado

irb(main):002:0> Test.new.test_method
"Doing something really important in module B"
"Doing something really important in module A"
"Inside method of class A"

Ahora creamos un objeto de tipo Test e invocamos sobre él el metodo “test_method”…!Pero que ha pasado aqui¡!De donde salen esa lineas¡No no pongamos nerviosos y averigüemos que pasa.

Cuando redefinimos el metodo included de la clase module, realizamos unos alias.
Para el modulo A:

• Nuevo nombre : test_method_A_without_filters,nombre antiguo: test_method
• Nuevo nombre : test_method, nombre_antiguo test_method_A_with_filters

Para el modulo B , lo mismo pero cambiando la A por una B.

El resultado de estos alias es el que vemos en la salida de irb, al invocar sobre un objeto de la clase Test
su metodo de instancia “test_method” lo primero que vemos no es “Inside method of class A” sino “Doing something really important in module B“,seguido de un “Doing something really important in module A” para finalmente ver nuestro esperado “Inside method of class A“,esto es asi porque:

1. El ultimo modulo incluido fue el B, por tanto su alias “sobreescribioo” al creado por el modulo A.Es decir al hacer Test.new.test_method en realidad estamos invocando a test_method_B_with_filters
2. Tras ejecutar este metodo, invocamos al metodo “original”, que en este caso no es el definido en la clase, sino el alias realizado por el modulo A
3. Tras ejecutar este ultimo alias, volvemos a invocar al metodo original (alias de “test_method_A_without_filters”) quien finalmente si que es el metodo de la clase Test

Utilizando caller podemos saber la stacktrace de nuestro programa y asi saber cual fue la direccion de los mensajes.Esto lo podemos ver en este trozo de la salida de irb,

"Backtrace:"
"./test30.rb:19:in `test_method_B_without_filters'"
"./test30.rb:30:in `test_method'"
"(irb):2:in `irb_binding'"
"/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'"
":0"

Teniendo en cuenta que las primeras lineas indican los ultimos mensajes.Tenemos que:

En la linea 30 vamos enviar un mensaje tras recibir uno con destino a “test_method” alias de “test_method_B_with_filters“,

28
29
30
31

  def test_method_B_with_filters
    p "Doing something really important in module B"
    test_method_B_without_filters
  end

En la linea 19 vamos a enviar un mensaje tras recibir uno con destino “test_method_B_without_filters”
el cual es un alias de “test_method“,

17
18
19
20

 def test_method_A_with_filters
    p "Doing something really important in module A"
    test_method_A_without_filters
  end

Como se puede apreciar es una forma bastante sencilla de añadir funcionalidad sin influir para nada en las clases.Y de aqui es de donde saque el titulo, porque literalmente estamos encadenando metodos.

Para terminar
Si alguien le extraña la coletilla _filters que utilize para hacer los alias , tiene su explicacion.Ultimamente estoy curioseando en el codigo de Rails, y para poder seguir un orden me voy guiando por el orden el que se procesan las peticiones ,gracias al debugger para webrick y otros servidores.Bueno la cosa es que llegue al fichero filters.rb donde me encontre con este codigo,

 module InstanceMethods # :nodoc:
      def self.included(base)
        base.class_eval do
          alias_method_chain :perform_action, :filters
          alias_method_chain :process, :filters
        end
      end
...

¿alias_method_chain?, no me sonaba para nada, asi que tras una consulta a google llegue a esto:

All over the internals of Rails you’ll find code like this in a module:

module Layout #:nodoc:
def self.included(base)
base.extend(ClassMethods)
base.class_eval do
alias_method :render_with_no_layout, :render
alias_method :render, :render_with_a_layout
# … etc
This makes it so that when the module is included into the base class, it adds behavior onto some method in that class without the method having to be aware of the fact that it’s being enhanced

En resumidas cuentas, que alias_method_chain hace lo que acabos de hacer nosotros pero un poquillo mejor ya que se puede aplicar a cualquier metodo, no solo a test_method como en nuestro caso.

Volviendo a lo de la coletilla _filters, la explicacion es que donde vi el primer ejemplo de alias_method_chain fue en el codigo indicado arriba y entonces fue lo primero que se me ocurrio.

Ayer aparecio una duda delante de mi y me asalto, ¿Metodos de clase privados?

La primera idea que me paso por la cabeza y que probe fue:

class Test
 
private
def Test.class_method
p "inside private class method"
end
 
end

Si pruebo este codigo en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
"inside private class method"
> nil

Podemos ver que no, que esto no funciona porque me deja llamar al metodo perfectamente y todos sabemos que eso no puede pasar ya que en ruby los metodos privados solo permiten ser invocados con un “self” explicito.Realmente lo que acabo de decir no es del todo cierto, ya que los utilizando el metodo send para enviar el mensaje da igual la visibilidad del metodo que lo reciva.

Lo que no entiendo es porque falla, supongo que sera porque la restriccion de visibilidad que implica private solo afectara a los metodos de instancia de la clase.Si alguien quiere aportar mas luz sobre esto…

Volviendo al tema, probemos con el metodo private_class_method.Este metodo cambia la visibilidad de cualquier metodo a privada.Veamos un ejemplo:

class Test
 
def Test.class_method
p "inside private class method"
end
 
private_class_method :class_method
end

Lo probamos,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
NoMethodError: private method `class_method' called for Test:Class
from (irb):2

Esto ya es otra cosa,es lo esperado.Este metodo esta muy bien ya que permite cambiar la visibilidad a que por ejemplo herede nuestra clase.

Pero aun nos queda una manera mas de definidir metodos de clase que sean privados.

Como en ruby todo es un objeto, las señoras clases tambien son objetos (de la clase Class).Por tanto tambien pueden tener metodos de instancia, que a efectos practicos se comportan como los metodos de clase definidos de forma normal y corriente en una clase.

¿Y como añado yo metodos de instancia a una clase?Pues hay varios metodos pero el mas sencillo (o por lo menos eso me parece a mi -se aceptan sugerencias) es el siguiente:

class Test
    class << self
      private
        def class_method
         p "inside private class method"
        end
    end
end

Lo que acabamos de hacer es abrir la metaclase o clase-virtual de la clase para añadir un el metodo class_method con visibilidad privada.Para el que no sepa que son las clases virtuales o metaclases, le recomiendo leer los enlaces que menciono al final del post.

Si ejecutamos esto en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
NoMethodError: private method `class_method' called for Test:Class
from (irb):2

Una vez mas, funciona correctamente.

Si quieres saber algo mas sobre las metaclasses o clases-virtuales te recomiendo que le heches un vistazo a:

Seein metaclasses clearly

Why virtual classes?