Sobre Materialize:
Documentación Materialize
La instalación será como indica en su web, a través de su gema:
Agregar la línea en el gemfile:
gem 'materialize-sass'
Después se correrá en bundle istall en la terminal para la instalación.
Una vez instalada la gema, se renombrará a application.sccs nuestra hoja de estilos principal que se encuentra en app/assets/stylesheets/ debido a que materialize trabaja sobre SASS y es por eso que la extensión debe quedar como SCCS
Dentro de esta hoja, importaremos los estilos, únicamente agregando la línea:
@import "materialize";
**En caso de que lo anterior no funcione, dentro del mismo directorio de stylesheets crearemos un nuevo archivo llamado materialize.scss y dentro se copiará el siguiente código:
@charset "UTF-8";
// Mixins
@import "materialize/components/prefixer";
@import "materialize/components/mixins";
@import "materialize/components/color";
// Variables
@import "materialize/components/variables";
// Reset
@import "materialize/components/normalize";
// materialize/components
@import "materialize/components/global";
@import "materialize/components/icons-material-design";
@import "materialize/components/grid";
@import "materialize/components/navbar";
@import "materialize/components/roboto";
@import "materialize/components/typography";
@import "materialize/components/cards";
@import "materialize/components/toast";
@import "materialize/components/tabs";
@import "materialize/components/tooltip";
@import "materialize/components/buttons";
@import "materialize/components/dropdown";
@import "materialize/components/waves";
@import "materialize/components/modal";
@import "materialize/components/collapsible";
@import "materialize/components/chips";
@import "materialize/components/materialbox";
@import "materialize/components/forms/forms";
@import "materialize/components/table_of_contents";
@import "materialize/components/sideNav";
@import "materialize/components/preloader";
@import "materialize/components/slider";
@import "materialize/components/carousel";
@import "materialize/components/date_picker/default.scss";
@import "materialize/components/date_picker/default.date.scss";
@import "materialize/components/date_picker/default.time.scss";
Después, en la propia hoja de application.scss se añadirá el require para que llame a la nueva hoja que se creó:
*= require materialize
Por último, para tener función de todos los elementos JavaScript dentro de app/assets/javascripts abriremos el application.js añadiremos también el require:
//= require materialize-sprockets
Y después, se hará el llamado a la función select:
$(document).ready(function() {
$('select').material_select();
});
Para hacer funcionar los iconos, en la vista que se usarán (o en el layout de application.html) se agregará la referencia de las fuentes de google:
<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
Mostrando entradas con la etiqueta Frontend. Mostrar todas las entradas
Mostrando entradas con la etiqueta Frontend. Mostrar todas las entradas
martes, 2 de agosto de 2016
lunes, 23 de mayo de 2016
Form Builder (Customizar forms en Ruby on Rails)
Si se necesita cambiar la estructura en la que se presentan los formularios, podemos crear nuestro propio form builder para personalizar plantilla, y poder reutilizarla en todos los formularios que deseemos.
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
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.
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|
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:
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:
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
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:
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) |
sábado, 23 de abril de 2016
Implementar Bootstrap en Ruby on Rails
Existen dos gemas para implementar Bootstrap en Ruby on Rail, la primera es bootstrap-sass, esta está desarrollada por el propio Bootstrap y son ellos quienes le dan soporte, la segunda es twitter-bootstrap-rails, la cual está desarrollada por usuarios de Rails y son quienes le dan soporte.
La ventaja de usar la segunda, es que como todo en rails, ofrecen una mejor forma de escribir el código, ahorrándonos líneas de código y presentando más elegante todo nuestro layout, pero en mi caso, opté por usar la desarrollada por el propio framework, debido a que muchas veces, yo trabajo con un diseñador para el frontend, al entregarme el maquetado, viene con la sitaxis pura del framework, por lo cual, al implementar la que está optimizada para rails, significaría una inversión nueva de tiempo, para reestructurar los contenidos del layout, sin mencionar que estoy mucho más familiarizado en la estructura original.
1.- Dar de alta la gema de rails en nuestro archivo gemfile, abriendo dicho archivo que se encuentra en la raíz y escribiendo: gem 'bootstrap-sass'
2.- Corremos el bundle install
3.- Agregamos la línea //= require bootstrap que hace referencia a la librería javascript en application.js siguiendo la ruta: app/assets/javascript/application.js
4.- Rails usa SASS, por lo cual deberemos cambiar la extensión de nuestro archivo css de la aplicación, una forma sería en la línea de comandos con mv, la otra simplemente en sublime, cambiando .css por .scss
5.- Finalmente integraremos bootstrap al SCSS, con la línea @import "bootstrap"; en app/assets/stylesheets/application.scss
*Nota:
Muchas veces, algunos componenetes, como los glyphicon no cargar correctamente una vez terminado el preceso, es por eso, que la línea se complementa importando también:
@import "bootstrap-sprockets"; @import "bootstrap";
De esta manera, Bootstrap quedó implementado en nuestra aplicación de Rails y podemos hacer uso de él sin ningún problema.
La ventaja de usar la segunda, es que como todo en rails, ofrecen una mejor forma de escribir el código, ahorrándonos líneas de código y presentando más elegante todo nuestro layout, pero en mi caso, opté por usar la desarrollada por el propio framework, debido a que muchas veces, yo trabajo con un diseñador para el frontend, al entregarme el maquetado, viene con la sitaxis pura del framework, por lo cual, al implementar la que está optimizada para rails, significaría una inversión nueva de tiempo, para reestructurar los contenidos del layout, sin mencionar que estoy mucho más familiarizado en la estructura original.
1.- Dar de alta la gema de rails en nuestro archivo gemfile, abriendo dicho archivo que se encuentra en la raíz y escribiendo: gem 'bootstrap-sass'
 |
| (clic para agrandar) |
2.- Corremos el bundle install
 |
| (clic para agrandar) |
3.- Agregamos la línea //= require bootstrap que hace referencia a la librería javascript en application.js siguiendo la ruta: app/assets/javascript/application.js
 |
| (clic para agrandar) |
4.- Rails usa SASS, por lo cual deberemos cambiar la extensión de nuestro archivo css de la aplicación, una forma sería en la línea de comandos con mv, la otra simplemente en sublime, cambiando .css por .scss
 |
| (clic para agrandar) |
5.- Finalmente integraremos bootstrap al SCSS, con la línea @import "bootstrap"; en app/assets/stylesheets/application.scss
*Nota:
Muchas veces, algunos componenetes, como los glyphicon no cargar correctamente una vez terminado el preceso, es por eso, que la línea se complementa importando también:
@import "bootstrap-sprockets"; @import "bootstrap";
 |
| (clic para agrandar) |
De esta manera, Bootstrap quedó implementado en nuestra aplicación de Rails y podemos hacer uso de él sin ningún problema.
jueves, 3 de marzo de 2016
Crear un controlador y usarlo como página principal
Después de haber instalado correctamente Rails, seguiría crear un controlador y hacerlo ver como nuestra página principal.
Nota:
Todo lo trabajado, se usa a partir del proyecto ya creado cuando se hizo la instalación.
1.- Crearemos el controlador con la siguiente sintaxis:
Donde:
principal => nombre del controlador que vamos a crear
index => nombre de la función que el controlador va a llamar
(pueden poner cualquier nombre)
2.- Esto nos generará 2 nuevos archivos dentro de nuestra aplicación y podemos comprobarlo en la ruta de controladores y de vistas, ambos con los nombres que escogimos.
El archivo de la vista, es un html y lo modificamos para comprobar su funcionamiento en:
localhost:3000/principal/index
(Recuerda que primero se debe levantar el servidor para poder visualizarlo)
Usando nuestro controlador como vista principal.
Haremos que este nuevo controlador, sea visible desde la vista principal, para convertirlo en el front de nuestro sitio:
1.- Vamos a dirigirnos a la carpeta de config y abriremos el archivo llamado routes.rb
2.- Dentro de ella vamos a encontrar una línea comentada de root, podemos usar esa, o podemos añadir una nueva, usando nuestro controlador antes creado:
3.- Regresamos al navegador, escribimos localhost:3000 y deberíamos estar viendo nuestra vista recién creada.
Nota:
La cadena de la línea 2, que comienza con get, le está indicando a rails que después de localhost:3000/ existe esa ruta, si la comentamos/borramos, al tratar de acceder a localhost:3000/principal/index marcaría un error de que dicho path no existe.
Nota:
Todo lo trabajado, se usa a partir del proyecto ya creado cuando se hizo la instalación.
1.- Crearemos el controlador con la siguiente sintaxis:
rails generate controller principal index
Donde:
principal => nombre del controlador que vamos a crear
index => nombre de la función que el controlador va a llamar
(pueden poner cualquier nombre)
2.- Esto nos generará 2 nuevos archivos dentro de nuestra aplicación y podemos comprobarlo en la ruta de controladores y de vistas, ambos con los nombres que escogimos.
El archivo de la vista, es un html y lo modificamos para comprobar su funcionamiento en:
localhost:3000/principal/index
(Recuerda que primero se debe levantar el servidor para poder visualizarlo)
 |
| (clic para hacer grandota) |
Usando nuestro controlador como vista principal.
Haremos que este nuevo controlador, sea visible desde la vista principal, para convertirlo en el front de nuestro sitio:
1.- Vamos a dirigirnos a la carpeta de config y abriremos el archivo llamado routes.rb
2.- Dentro de ella vamos a encontrar una línea comentada de root, podemos usar esa, o podemos añadir una nueva, usando nuestro controlador antes creado:
 |
| (clic para hacer grandota) |
3.- Regresamos al navegador, escribimos localhost:3000 y deberíamos estar viendo nuestra vista recién creada.
Nota:
La cadena de la línea 2, que comienza con get, le está indicando a rails que después de localhost:3000/ existe esa ruta, si la comentamos/borramos, al tratar de acceder a localhost:3000/principal/index marcaría un error de que dicho path no existe.
Suscribirse a:
Entradas (Atom)