Un tipo de dato indica un conjunto de valores que significan lo mismo , hay algunos tipos que no representan valores en la aplicación que se ejecutan.
Los tipos son la puesta en vigor de la clase de objetos, los objetos con distintos tipos no podrán intercambiarse o al menos no totalmente, si se lograran intercambiar solo de formas muy limitadas.
Los middleware, son funciones que nos permiten agregar filtros a cada petición HTTP realizada por un usuario en una aplicación. La finalidad de este componente es disminuir la carga de trabajo en los controladores y proporcionar una solución mucho más simple y estándar a la hora de aplicar las restricciones necesarias en el proyecto. Ver post
Esta es la lección 12 de nuestro curso introductorio de Laravel 5.1, si no estas al día con el avance de este curso te invitamos a ver todas las lecciones.
A partir de Laravel 5.1 se incluye la posibilidad de agregar y pasar parámetros a los Middleware.
Esto es muy útil dado que nos permite reusar un Middleware en más de un escenario diferente. El caso real más común sería un Middleware para controlar el acceso a la aplicación dependiendo del rol del usuario y esto es lo que veremos en la lección de hoy.
Regístrate para ver ésta y cientos de lecciones exclusivas.
Esta es la lección 11 de nuestro curso introductorio de Laravel 5.1, si no estas al día con el avance de este curso te invitamos a ver todas las lecciones.
Sin importar si Laravel incluye 3, 10 o 100 Middleware por defecto, cada aplicación posee reglas de negocio muy distintas, y parte de estas reglas definen a qué secciones o acciones va a tener acceso un usuario y entre una aplicación y otra esto puede variar muchísimo.
La manera más conveniente de traducir estas reglas a código dentro de nuestro proyecto de Laravel es a través de los middleware.
Regístrate para ver ésta y cientos de lecciones exclusivas.
Esta es la lección 10 de nuestro curso introductorio de Laravel 5.1. Ver todas las lecciones.
Los middleware son procesos que pueden ser ejecutados en un segundo plano al momento de realizar una petición con la finalidad de «filtrar» cierta información o verificar si dicha petición cumple con los parámetros requeridos.
En una clase anterior hablábamos sobre las abstracciones y como estas definían el comportamiento general de un «objeto», en programación orientada a objetos, estas abstracciones pueden ordenarse y clasificarse, a esto se le conoce como Jerarquia.
Vamos a centrarnos en las dos jerarquías más importantes: la relación de clases y relación de objetos.
Esta es la lección 9 del curso introductorio de Laravel 5.1
Ir al indice de lecciones del curso.
Una característica muy importante que tu cliente te va a solicitar si tu aplicación contiene un módulo de registro, es la validación de email para activar la cuenta del usuario.
No hablo de que el campo contenga un email en formato válido, sino de que dicha cuenta de correo electrónico exista y pertenezca al usuario que intenta registrarse.
Regístrate para ver ésta y cientos de lecciones exclusivas.
Artisan provee una serie de comandos muy útiles al momento de desarrollar aplicaciones con Laravel, puedes crear elementos como controladores, middelwares, seeders, modelos, etc. y puedes interactuar con ellos al ejecutar una migración, solicitar información de las rutas del sistema etc.
Hoy vamos a ver un poco mas allá de estas funcionalidades y trataremos de construir nuestro propio comando accesible desde la consola. Tranquilos! es mucho mas fácil de lo que parece.
Esta es la lección 8 del curso introductorio de Laravel 5.1.
Ver todas las lecciones de este curso.
Muchas personas me han preguntado si es posible hacer la autenticación con un campo de nombre de usuario en vez del campo de email. Lo que muchas personas no saben es que la única credencial obligatoria es la de contraseña (password) y aún así no requieres tener un campo de texto llamado password en el HTML ni una columna o atributo llamado password en la tabla o el modelo respectivamente. También puedes pasar condiciones extras al método Auth::attempt como veremos en el video de hoy.
Regístrate para ver ésta y cientos de lecciones exclusivas.
En la lección anterior aprendimos a almacenar emails como logs de nuestra aplicación, para poder probar el envío del recordatorio de contraseña.
Pero, ¿Qué sucede si no queremos enviar un email real, pero tampoco queremos guardarlo como un simple log?
En la lección de hoy, exploraremos una solución intermedia, que nos permita comprobar que el email realmente se está enviando a un servidor (de prueba) sin arriesgarnos a enviar SPAM a usuarios reales o llenar de emails de prueba nuestra propia bandeja de entrada.
Regístrate para ver ésta y cientos de lecciones exclusivas.