Esto podría ser relacionado a crear un parcial, pero en este caso, se trata de un layout especial para los formularios para poder hacerlos dinámicamente, ahorrándonos bastantes líneas de código y aprovechando el potencial que rails nos brinda.
Se muestra como ejemplo un formulario de creación de un Artículo, creado a través de un scaffold. Se modificará su estructura para también simplificar su contenido y mostrar el formulario con las clases de bootstrap.
Esta sería la estructura común que tendría un formulario:
**Notar que para el HTML se está usando HAML
 |
| (clic para agrandar) |
1.- Lo primero será crear la carpeta dentro que contendrá todos los forms. La carpeta se deberá nombrar como form_builders y dentro de ella crearemos el archivo que contendrá la estructura. El nombre del mismo, es a criterio propio, pero una vez creado, la clase declarada deberá coincidir con el archivo.
 |
| (clic para agrandar) |
2.- Se limpiará todo el código del form de articulos, los divs, labels y errores se removerán para solo dejar las impresiones de los campos. y se indicará en la parte superior, que este formulario usará el builder BootstrapFormBuilder, haciendo referencia a la clase creada en el punto anterior:
= form_for @article,builder: BootstrapFormBuilder do |f|
 |
| (clic para agrandar) |
3.- Se puede ver desde el punto anterior, como se ha reducido el código, mostrándose de una manera más sencilla y legible. Cada campo en el formulario contiene un método, este recibe el nombre según el tipo al que pertenece, errors es el método que contiene los errores del formulario, text_field es el método que indica que el input es de tipo text, etc. Cada uno de ellos deberá definirse en nuestro builder BootstrapFormBuilder, para que puedan ser usados.
El primero a definir será el método para los errores:
def errors
if object.errors.any?
content_tag :div, class:"alert alert-dismissible alert-danger" do
content_tag(:h2, "Errores") +
content_tag(:ul) do
list = ""
object.errors.full_messages.each do |error|
list += content_tag :li, error
end
list.html_safe
end
end
end
end
Primero se validará con un if si existen errores, de ser así, entonces los imprimirá. Cuando queremos definir qué será lo que mostrará nuestro método, podemos usar content_tag el cuál nos ayudará a desplegar el HTML(HAML). Si queremos anidar los divs por ejemplo, usaremos un do, esto es un bloque que indicará que el contenido estará dentro del mismo, ejemplo:
HAML:
.container
.col-md-8
%h2 Título
content_tag:
content_tag :div, class:"container" do
content_tag :div, class:"col-md-8" do
content_tag :h2, "Titulo"
end
end
Se crea una lista (en primer instancia, vacía), y esta recibirá cada uno de los mensajes de error arrojados por la iteración que estamos haciendo a object.errors y finalmente los mostramos como un html.
Al estar creando nuestro propio builder, content_tag no está declarado, ya que ese se encuentra en la estructura original, y para eso es necesario que se declaré en nuestro builder. En lugar de eso, aprovecharemos los helpers de rails y delegaremos a @template (que es dónde está declarado content_tag) al nuestro, y de esta manera podemos usarlo dentro de nuestro builder. Al final, el código debería verse de esta menera:
 |
| (clic para agrandar) |
4.- Definir el método text_field. Primero se observará el tipo de estructura que usa bootstrap para la creación de formularios, viendo que cada campo se encuentra dentro de un div.form-group y dentro se encuentra el label y el tipo de input, que en este caso se define a través de nuestro método:
 |
| (clic para agrandar) |
Así que con esa estructura, procedemos a crear nuestro método para todos los input que sean de tipo text:
def text_field name, *args
options = args.extract_options!
if options.has_key?(:class)
options[:class] += "form-control"
else
options[:class] = "form-control"
end
content_tag :div, class:"form-group" do
content_tag(:label, name, name: name ) + super(name,options)
end
end
En la declaración del método se escribirán qué parámetros recibirá, en este caso, será name, el cual contiene el nombre del campo y *args que este se usará en caso de que se quiera definir clases personalizadas a cada input además de que se debe declarar por defecto (form-control). A raíz de este 2do parámetro, se indica la validación, donde options será el hash que extraerá los argumentos que se escribieron en cada campo y se validará si existen nuevas clases, de ser así, options tendrá la clase por defecto, más la(s) clase(s), de lo contrario, solo tendrá la clase por defecto, es decir:
En nuestro form, para definir una nueva clase lo deberemos poner como 2do parametro, de lo contrario, solo asignará por defecto la clase form-control:
f.text_field :name, class: "mi-clase mi-clase-2 "
Finalmente, se escribe el content_tag que imprimirá nuestras estructura del form, donde se usa un super, que es una palabra reservada de ruby, que llama al método de la clase padre. En este caso, estaría mandando a llamar al método de FormBuilder que es nuestra clase padre, dónde se generarán los controles según los parámetros que estamos enviando, contenidos en name y options (el nombre del campo y las clases generadas) algo parecido como se hizo anteriormente con @template. De esta manera, se está creando el content_tag con el label y el super con el input.
Este método quedaría enteramente reutilizable para los demás inputs que se necesiten, solo sería cuestión de copiar el código para crear un segundo método, y cambiar el text_field por text_area, url_field, email_field, etc..
5.- Refactoring del código. El generar muchos métodos que hacen exactamente lo mismo, no sería lo más apropiado, y se debería seguir la filosofía de "Don't repeat yourself", por lo cuál, se reestructuraría el código, para que en lugar de generar muchos métodos iguales, generaríamos un pequeño snippet para que los métodos sean autogenerados dinámicamente, y esto es conocido cómo metaprogramming:
[:text_field,:text_area,:url_field,:email_field,:number_field].each do |metodo|
define_method metodo do |name,*args|
options = args.extract_options!
additional_classes = "form-control floating-label"
if options.has_key?(:class)
options[:class] += additional_classes
else
options[:class] = additional_classes
end
options[:placeholder] = name.capitalize
content_tag :div, class:"form-group margenss" do
super(name,options)
end
end
end
 |
| (clic para agrandar) |
Dentro de un arreglo, incluiremos los nombres de los métodos que contendrían el mismo código, después, estos se irán iterando con un each e irán siendo guardados en la variable metodo. Se hace uso del método define_method que como su nombre indica, se encarga de definir un método, y este será según la iteración con la variable metodo, pasándole los parametros de name y *args.
Se agrega la variable additional_classes la cuál contiene las clases por defecto para los input (por cuestión de estilos se añadió la 2da clase floating-label para dar usar los forms de material design) y esta clase ahora es usada en las validaciones del options.has_key.
Se declara el options[:placeholder] = name.capitalize para que los placeholders tengan letra capital (recordar que options recoje todos los argumentos que van en el después del name en el form, es por eso que podemos usar los símbolos como :class, :placeholder, :id, etc), y finalmente, se eliminó la impresión del label y simplemente se dejó el input generado por el super.
6.- El botón de submit. Una vez construido todo el form dinámico, solo quedaría definir nuestro submit para poder generar el botón guardar los artículos. De igual manera, el método recibe los argumentos(*args) que se definan en el form, se añade el bloque del content_tag para que todo esté dentro de un div y finalmente se muestra el super con los argumentos recibidos y con una clase por defecto:
def submit(*args)
content_tag :div do
super(*args,class:"btn btn-success")
end
end
El resultado final de este formbuilder sería el siguiente:
 |
| (clic para agrandar) |
 |
| (clic para agrandar) |
No hay comentarios:
Publicar un comentario