Active Admin, una gema de administración de recursos con RubyOnRails – Primera parte


Ruby on RailsHace relativamente poco, había comentado en Twitter que esta gema sería muy interesante analizarla y/o conocerla por su aportación como panel de gestión y facilidad de desarrollar hasta un punto en el que se nos pueden plantear dilemas de hasta dónde es capaz de llegar  y sobre todo la integración en nuestro proyecto. Voy a comentar mi experiencia de uso de esta gema que ha sido muy interesante y quiero compartir. Lo primero doy por supuesto que trabajas en proyectos RubyOnRails y que ya dispones del entorno de trabajo por si te interesa probarla en tu PC. Te dejo la documentación de ActiveAdmin y el repositorio de GitHub. Como digo es una herramienta que te facilita las cosas, pero como todo, tiene un límite, los inicios es pegarte y pegarte mucho con ella para descubrir funcionalidad, hasta dónde puedes llegar con ella y dónde comienza tu experiencia real para ingeniártelas en incrementar funcionalidades.  Yo te voy a contar mis pasos para que sea un poco más ameno el encuentro con esta Gema.

Primero, lo explicaré sobre un proyecto que no contenga nada en especial para ver el funcionamiento, antes de meternos con los accesos al panel y la construcción de opciones que necesitamos en un proyecto. Arrancamos, primero nos creamos nuestro proyecto RoR con el comando rails new para obtener nuestra estructura y poder modificar los fuentes, el nombre, puedes ponerle el que te guste, pero por dar una idea,  rails new active_admin, con esto ya te crea la estructura que ya conocemos de RubyOnRails. Hagamos una parada en el fichero de Gemfile y fíjate que tengas las gemas incorporadas para que las tengas disponibles, son :

gem ‘activeadmin’ y gem ‘meta_search’

Recuerda ejecutar bundle o bundle install y cuando lo tengamos hecho las instalaciones de nuestras gemas, debemos terminar la instalación de Active Admin con:

rails generate active_admin:install (instalación por defecto y control de acceso por arte de Active Admin)

rails generate active_admin:install –skip-users (instalación sin control de acceso por arte de Active Admin y necesitamos disponer de nuestro propio sistema de sesiones)

Ahora lo que nos queda es realizar nuestras migraciones de la base de datos con el comando rake db:migrate y nuestro primer paso ya lo hemos superado. Ahora ejecuta rails s y verifica que arranca bien, ve al navegador y comprueba que ves la página con localhost:3000/admin. Como puedes comprobar, la página web que acaba de generar, no hay mucho que puedas hacer, con lo que vamos a necesitar crear nuestros propios recursos que estarán ligados a un modelo que podemos disponer, si estamos integrando con nuestra App o por contra si estamos iniciando su construcción, necesitamos crear los modelos. Por tanto en nuestro caso, vamos a necesitar una opción en la que nos permita gestionar nuestros propios usuarios. El Framework ActiveAdmin utiliza lo que se denomina recursos “resources“. Para eso ejecutamos la construcción de nuestros recursos con:

rails generate active_admin:resource “MiPropioRecurso” por ejemplo AdminUser

Hagamos otra breve parada para la configuración de los accesos a nuestro panel. Lo podemos hacer de dos formas posibles, una la que por defecto gestiona Active Admin y la otra nuestra autenticación propia. Si nos vamos a nuestro fichero de configuración en config/initializers/active_admin.rb disponemos de:

# == Site Title
config.site_title = “Active Invoices” Nombre del panel de administración, este parámetro no tiene mayor explicación.

# == User Authentication

config.authentication_method = :authenticate_admin_user! Si es únicamente un directorio /admin por defecto el namespase es admin y podríamos dejarlo así. 

config.namespace :admin do |admin|  Si necesitamos varios directorios /admin, /alive, /user..etc tendremos que definir los namespaces de cada uno tal cual lo estamos viendo.
          admin.authentication_method = :authenticate_admin_user!
end

config.namespace :alive do |alive|
         alive.authentication_method = :authenticate_alive_user!
end

Un buen lugar para las definiciones sería nuestro aplication_controller.rb

def authenticate_alive_user!
         authenticate_user!
         redirect_to root_url unless current_user.is_alive?
end

def authenticate_admin_user!
        authenticate_user!
        redirect_to root_url unless current_user.is_admin?
end

# == Current User Definimos los métodos para nuestra autenticación de usuarios en el panel tanto del login como del logout
config.current_user_method = :current_admin_user La autenticación del propio ActiveAdmin

config.current_user_method = :current_user Nuestra propia autenticación
# == Logging Out

config.logout_link_method = :delete Método que aplicaremos para el logout del panel

# == Root

#
# Set the action to call for the root path. You can set different
# roots for each namespace.
#
# Default:
# config.root_to = ‘dashboard#index’

config.namespace :alive do |alive| Para los namespaces creados anteriormente los root path lo definimos así
         alive.root_to = “my_alives#index”
end

# == Admin resources
config.namespace :admin do |admin|
        admin.root_to = “users#index”
end

config.logout_link_path = :destroy_user_session_path

config.allow_comments = false Para los comentarios que se puedan generar debe estar a true o false si no los necesitamos

# To load a stylesheet:

config.register_stylesheet ‘fixes.css’ Para las hojas de estilos propias

config.load_paths << Rails.root.join(“app”, “alive”) Para las cargas de los nuevos directorios fuera del rango de /admin

Sigamos con la construcción de los recursos de ActiveAdmin. Piensa que, si ya tenemos construido nuestro modelo, por ejemplo users.rb, debería llamarse igual nuestro recurso rails generate active_admin:resource User. En nuestro caso ya hemos ejecutado la generación de nuestro recurso AdminUser y lo podemos ver en el directorio app/admin/admin_user.rb el controlador, que no dispone de código alguno y en el que tendremos que personalizar el código. Primero, algunas cosas a considerar en modo de orden de colocación, ya que en algunos casos en función de la posición puede que no nos funcione como sería el caso si colocamos una etiqueta label de menu :label => “My Menu” y después colocamos una etiqueta de subopciones que veremos en breve como la etiqueta menu :parent => “Items”. El orden correcto debería ser 1) menu :parent y 2) menu :label en el caso de necesitar ambas. Pero sigamos, las primeras líneas de nuestro controlador podrían disponer de:

actions :all, except: [:new, :create] Tipo de acciones que queremos gestionar todas las acciones menos new y create

filter :title si queremos realizar búsquedas para filtrar por condiciones, considera que estas peticiones son del tipo like, esto penaliza.

filter :title, :label => I18n.t(“admin.label.title”) podemos personalizar los filtros, por defecto nos muestra el nombre del campo, en este caso title, si queremos poner otro esta sería la forma elegante con i18n.

Llegado a este punto podemos estar pensando en que necesitaremos realizar consultas a nuestros datos, en ese caso hablaremos de los scopes, que son elementos de filtrado adicional interesantes y no están relacionados con los que aparecen en la parte derecha (filtros like):

scope :all, :default => true
scope :due_this_week do |tasks|
          tasks.where(‘due_date > ? and due_date < ?’, Time.now, 1.week.from_now)
end
scope :late do |tasks|
           tasks.where(‘due_date < ?’, Time.now)

end

scope :mine do |tasks|

          tasks.where(:admin_user_id => current_admin_user.id)

end

o podríamos llevarnos los “where” al modelo, por ejemplo:

tendríamos en el controlador de admin:

scope :all, default: true
scope :due_this_week
scope :late

y en el modelo definimos los where:

scope :due_this_weekwhere(‘due_date > ? and due_date < ?’, Time.now, 1.week.from_now)
scope :latewhere(‘due_date < ?’, Time.now)

Sigamos con las partes que puedes implementar, tenemos los bloques de index, show y view y finalmente para edit, también podemos incorporar nuestros propios botones de ejecución. Comenzamos con el bloque de index en los que comienza con column y el campo de nuestro modelo en este caso :user, si queremos que no sea nuestra columna ordenable ascendente o descendente, ponemos al final column :title, :sortable => false, si queremos personalizar nuestros literales y no los que por defecto mostraría (:title muestra title como literal de columna) lo podemos hacer o directamente “My Title” o con i18n column I18n.t(“admin.label.title”) . Si estamos pensado en que nuestro recurso se vea en otra pestaña de nuestro navegador, por ejemplo imagínate que tienes una página de post que se ve en el frontend y desde nuestra administración de post, queremos que se vea tal como se vería en el navegador de nuestros usuarios, para eso necesitamos crear un bloque column do |post| ….. end y la línea de link_to, es decir link_to I18n.t(“admin.label.show”), post_path(post), target: “_blank”. Finalmente podemos obtener de una forma automática si queremos las opciones View, Edit y Delete con default_actions:

index do
     column :user
     column :title, :sortable => false
     column I18n.t(“admin.label.post”) do |post|
           link_to I18n.t(“admin.label.show”), post_path(post), target: “_blank”
     end
     default_actions
end

En los casos en los que necesitamos personalizar las opciones default_actions por las nuestras propias, podrías hacer algo como lo siguiente:

index do
          column :name
          column :email do |client|
                    if client.email
                                   mail_to client.email, client.email
                    else
                                   “-“
                   end
          end
          column :address do |client|
                          truncate client.address
          end
          column :phone
          column do |client|
                         link_to(“Details”, admin_client_path(client)) + ” | ” + \
                         link_to(“Edit”, edit_admin_client_path(client)) + ” | ” + \
                         link_to(“Delete”, admin_client_path(client), :method => :delete, :confirm => “Are you sure?”)
          end

end

En la segunda parte de este mismo post, hablaremos de más bloques de ActiveAdmin interesantes como, bloques show, form, los action_item, sidebar, entre otras muchas más.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s