Archivo

Archive for the ‘PHP’ Category

Expresiones Regulares en PHP

Funciones PHP

preg_match
Nos permite evaluar si un string hace match con una expresión regular. Por ejemplo, para validar un email haríamos lo siguiente

function verificar_email($email)
{
   if(preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+$/",$email))
   {
      return true;
   }
   return false;
}

Otros ejemplos interesantes pueden ser:
1. verificar si un password es seguro

function verificar_password_strenght($password)
{
   if (preg_match("/^.*(?=.{8,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).*$/", $password))
      echo "Su password es seguro.";
   else
      echo "Su password no es seguro.";
}

2. Verificar el fomato de una IPv4

function verificar_ip($ip)
{
   return preg_match("/^([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])" .
"(\.([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3}$/", $ip );
}

3. Verificar formato de número telefónico en EU

function verificar_telefono_eu($telefono)
{
   $regex = '/^(?:1(?:[. -])?)?(?:\((?=\d{3}\)))?([2-9]\d{2})'
.'(?:(?$0', $text);
}

preg_replace

Busca un patrón y si hace match se sustituye éste por un remplazo definido como una cadena o simplemente la re ordenación de datos dentro del patrón mediante retroreferencias. Éstas son simplemente una sintaxis para hacer referencia a los matches que ocurrirán al ejecutar una expresión regular. Por ejemplo, para convertir una fecha en formato YYYY/MM/DD a formato DD/MM/YYYY podemos utilizar retroreferencias:

function cambiar_formato_fecha($fecha)
{
   return preg_replace("/([0-9]{4})\/([0-9]{2})\/([0-9]{2})/i","$3/$2/$1",$fecha);
}

Refiriéndose $1 al primer match ([0-9]{4}) y así sucesivamente. Entonces esta función busca un patrón de fecha YYYY/MM/DD y lo cambia a DD/MM/YYYY.

Anuncios
Categorías:Desarrollo, PHP Etiquetas: ,

Composer

Es una librería y ejecutable que gestiona otras librerías para PHP. Resuelve las dependencias de las librerías que vayamos a instalar (se descarga todas las librerías necesarias para que funcione la nuestra) y gestiona el autoload de las librería en nuestro proyecto. Además es el sistema elegido para instalar la mayoría de los grandes frameworks actuales, además de un sinfín de librerías que podemos utilizar en cualquiera de nuestros proyectos. Composer debe implementarse en nuestro sistema (por el ejecutable) y nuestro proyecto para poder hacer uso de él.

Para instalar composer en nuestro sistema, primero necesitaremos tener instalar algún paquete con Apache, PHP….pero el procedimiento es muy parecido. Lo primero es acceder a la página de Composer y descargar el ejecutable (Windows – siguiente, siguiente…y listo!) o copiar la URL para la descarga. Ésta descarga se puede realizar mediante curl (utilidad de transferencia de archivos muy potente), o también mediante la el comando de php. En el caso de no tener curl:

sudo apt-get install curl

Luego desde una línea de comando ejecutar el siguiente comando:

curl -sS https://getcomposer.org/installer | php

Sin curl

php -r "readfile('https://getcomposer.org/installer');" | php

Composer se habrá descargado en la carpeta donde estemos actualmente pero deberemos moverlo a una carpeta del sistema, para que ese ejecutable sea global y no tener que estar escribiendo la ruta del mismo todo el tiempo. Este proceso en Windows no es necesario (el instalador lo añade solo al Path).

mv composer.phar /usr/local/bin/composer

Para instalar Composer en nuestro proyecto debemos de crear en el raíz del proyecto un archivo llamado composer.json (ver sintaxis) que como su extensión indica será en formato json (todo son cadenas “” dentro de objetos JS {}) . No todos los parámetros del enlace son necesarios, los más importantes son:

  • name: nombre del proyecto
  • description: descripcion del proyecto
  • type: project, library…
  • authors: nombre de autor o autores y datos de los mismos [array]
  • require: dependencias del proyecto P.E (“php”: “>=5.3.0”)
    • para buscar librerías para nuestro proyecto (Packagist)
  • autoload: reglas para la carga automática de librerías
    • classmap: array con las carpeta/s  de includes
    • psr-4: especificación de un estándar para el autloading de clases y otras cosas.

Una vez creado el composer.json ejecutamos desde la raiz del proyecto:

composer install

Y se instalarán todas las librerías necesarias, además de crearse las carpetas necesarias de composer en el proyecto (/vendors) y actualizarse solo el autoload del proyecto!

Una última cosa, para que Composer funcione en nuestro proyecto deberemos incluir la siguiente línea en el index o bootstrap de nuestro proyecto:

require 'vendors/autoload.php';
Categorías:Desarrollo, PHP

Apuntes de PHP

La serie “Apuntes de…” sirve para documentar información que se utiliza, ya sea por recomendación o por imitación pero sin saber  demasiado bien porque, así como plasmar algunos trucos  muy interesantes, dado que la memoria es finita. (Aunque éste es el objetivo del blog..)

Algo de POO…

(extraído de Cristalab)

Cuando empecé en el mundo del PHP no entendí demasiado bien el uso de las interfaces en la POO, pero encontré una página (Cristalab) donde hacen una comparativa con un juego de rol bastante buena. En resumen podría decir que:

  • Es una clase vacía y genérica, dado que sólo se definen los nombres y parámetros de los métodos, que luego tendrán que desarrollarse obligatoriamente en las clases que la implementen (conocidos como métodos abstractos). Al desarrollar el contenido de estos métodos en la clase pueden cambiar su funcionalidad según ésta. Estos métodos han de ser públicos.
  • Las interfaces admiten la herencia múltiple entre ellas y además una clase puede implementar más de una interfaz. Esto puede ser útil cuando necesitemos que una clase extienda varios métodos (metiendo esos métodos en interfaces y extendiendo de las interfaces
interface a
{
    public function one();
    public function two();
}

interface b
{
    public function one()
    public function three();
}

interface c extends a, b
{
    public function four();
}

interface d
{
    publif function five();
}

class newClass extends c, d
{
    public function one(){
       //
    }
    public function two(){
       //
    }
    public function three(){
       //
    }
    public function four(){
       //
    }
    public function five(){
       //
    }
}
  • También pueden contener constantes, pero no propiedades. Se puede acceder a éstas, pero obviamente no sobreescribirlas.
interface a
{
    const b = 'Constante';
}
echo a::b;

Todo esto está bien, pero entonces ¿qué son las clases abstractas?

  • Lo primero, recordar que una clase con un método abstracto es abstracta!
  • Pues son clases padre que para usarlas hay que heredarlas, no se pueden instanciar.
  • Pueden contener métodos abstractos y no abstractos (desarrollados)
  • Solo se puede heredar de una clase abstracta (Herencia simple).

En general podemos decir que si una clase abstracta tiene todos sus métodos abstractos la estaremos tratando como una interfaz.

Capturar el flujo de salida en una variable

ob_start();
-Operaciones para el flujo de salida (include, echo...)
$var = ob_get_clean();

Funciones Utiles

  • extract($array_asoc): extrae del array asociativo tantas variables como keys tenga el array  y con el mismo nombre y con el valor contenido en el elemento etiquetado con esa key.
  • array_splice($array, $offset, [$length],[$replace = array()]): devuelve un array con los elementos seleccionados por la posición inicial $offset (posición real 1,2…) y la cantidad de elementos a escoger $length (admite número negativos) estos elementos se pueden sustituir por otro array de valores $replace.
    • Ej: array_splice ($array, 0 , -1) elimina el ultimo elemento de un array
  • array_shift ($array): Elimina el primer elemento del $array
  • array_push ($array, $value): añade $value al final de $array
  • array_unshift ($array, $value): añade $value al principio de $array
Categorías:Desarrollo, PHP

Stitch 626 Framework

NOTA: el nombre del framework se debe a que me encanta este personaje, pero sólo lo utilizaré mientras esté en desarrollo por posibles problemas de copyright 😛

Este proyecto será un framework de PHP que nace de la curiosidad por aprender PHP y como funcionan los grandes frameworks (como Symfony, Laravel…), además de implementar mis propias ideas, pero siempre orientado a pequeños proyectos.

Los grandes frameworks de PHP son muy poderosos, pero su curva de aprendizaje puede ser exponencial debido por ejemplo:

  • A que usan varios lenguajes dentro del mismo, uno para plantillas, otro para el ORM, además de la particularidades de su propio código PHP,  las posibles limitaciones o dificultades que podrían suponer la interconexión de cada componente.
  • La magia interna que poseen, que al principio es estupenda pero a la larga, puede impedir entender como funciona y dificultar la detección de posibles errores.

Por otra parte éstos frameworks fueron creados por alguien que también empezó de cero (o no) alguna vez, implementando sus ideas y lo que creía que era mejor en su momento. Luego éstas criaturas fueron creciendo hasta convertirse en lo que son hoy, con el apoyo de las comunidades de adeptos obtenida y de un posible equipo de trabajo. Mi framework intenta seguir una filosofía “RISC”, es decir, hacer pequeñas cosas combinables para hacer cosas más grandes y ser lo más versátil posible, usar sólo PHP para facilitar en la medida de lo posible tareas comunes y repetitivas.

Su estructura es MVC (Model View Controller), aunque una versión fue HMVC (Hierarchical Model View Controller) éste último esquema se compone de pequeñas aplicaciones que cada una de ellas usa un patrón MVC y pueden ser independientes unas de otras. Ese esquema no terminó de convencerme porque aunque parece ser el más útil, sobre todo en proyectos gigantes dada la posible reutilización de éstas pequeñas aplicaciones, creo que excede de  la intención de éste framework, por lo que decidí cambiar a MVC de nuevo.

El único punto de entrada a la aplicación es el controlador frontal (app.php), cuando se introduce una URL el controlador frontal carga el KERNEL y llama al ROUTER el cual parsea dicha URL y carga el fichero de rutas para comparar dicha url con las rutas y así buscar que controlador y que acción debe ejecutar.

Dentro del KERNEL….

El ROUTER he decidido hacerlo autónomo, es decir, que no dependa o lo haga lo menos posible de .htaccess o del servidor, aunque son necesarios para las urls amigables.

El MODELO, esá basado en un solo archivo el cual contienen la definición de la tabla y los métodos asociados a dicha tabla. Este esquema responde a una cuestión de simplicidad, es mas sencillo buscar en un solo archivo que en 2 o en 3. La definición de la tabla se realizará mediante anotaciones de comentarios con un comando especial y luego se definirá con comandos SQL estandar.

Por otra parte las librerías se basaran en un query builder que contempla tanto funciones de consulta, edición y construcción de tablas

Los FORMS se integrarán en las vistas, obedeciendo también a un criterio de simplicidad y minimización de archivos, pero cumpliendo criterios de reusabilidad. Se implementará con un clase abstracta para no tener que instanciar ninguna clase dentro de las vistas.

Los GRIDS siguen definiéndose dentro del controlador, en lugar de en las vistas como sus hermanos FORMS, esto se debe a a varios factores:

  • Los grids necesitan de un paginador basado en la URL y desde la vista no hay control sobre la URL o sería muy complejo de implementar, concepto contrario a este framework.
  • También necesitan acceso al modelo que también ha de ser paginado.
Categorías:Desarrollo, PHP, Proyectos