Código al Descubierto

CSS generado en PHP

ZoItrix — Mon, 28 Jul 2008 19:43:06 +0000

I. Introducción

Antes de comenzar a explicar el uso de hojas de estilos en PHP, recordar que se haga un repaso previo a qué son las hojas de estilo (CSS) en la programación web en caso de no saber de qué estamos hablando.

Pues bien, el objetivo del siguiente artículo, muy sencillo, todo hay que decirlo, es mostrar como podemos hacer una hoja de estilos (el típico estilos.css donde se definen todos los estilos de nuestra página) pero usando variables en PHP.

¿Qué ventajas tiene esto? ¡Muy sencillo! ¿Os imagináis poder crear una hoja de estilos de forma dinámica en función de lo que se introduzca en una base de datos? Darle al usuario la posibilidad de cambiar el diseño web simplemente rellenando formularios. La hoja de estilos se conectará a la base de datos (¡Recordad! ¡Estamos ante un fichero PHP!) y tomará como colores y propiedades aquellas definidas por el usuario.

Un ejemplo muy sencillo podría ser disponer de un pequeño formulario para definir las etiquetas

,

o las capas que se vayan a implementar en la web. Modificando adecuadamente ese formulario, luego, la hoja de estilos recogerá los valores de la base de datos y se usará un estilo totalmente dinámico.

¿Qué necesitamos para implementarlo? Muy sencillo. Básicamente se necesitan dos cosas:

Fichero PHP donde se tenga el diseño de la web y se haga referencia a la hoja de estilos.

Fichero PHP que “hará” de hoja de estilos.

II. Hoja de estilos

La hoja de estilos debe ser un fichero en PHP. Supongamos, “estilos.php” y en su contenido debe figurar lo siguiente:

header(“Content-type: text/css”);
$color = “blue”;
echo “
h2{
color: $color;
font-weight: bold;
font-size: 1.2em;
text-align: left;
}
“;
?>

Donde pone “h2″ se deberá colocar toda la hoja de estilos que se tiene prevista implementar. De esa forma, la variable $color (cuyo valor es “blue”) será la que se emplee para definir el color de la etiqueta H2. Imaginaos que en vez de coger esa sencilla variable, hacemos una consulta a la base de datos. La funcionalidad y potencia del sistema varía drásticamente.

La clave del código anterior reside en la primera línea: “header(“Content-type: text/css”);” línea que hará que el fichero en PHP sea del tipo CSS. De esta forma estamos engañando al sistema implementando una hoja de estilos con PHP.

Lo último que queda por implementar es hacer referencia a la hoja de estilos en la página diseñada.

III. Referencia en páginas PHP

El procedimiento es exactamente el mismo que si de una hoja CSS se tratara. La única diferencia reside en que en vez de referenciar a un fichero con extensión “.css” se hará referencia a un fichero con extensión “.php”:

PRUEBA

Con el sencillo ejemplo anterior se ha configurado una hoja de estilos en PHP. Como podéis observar, la implementación es muy sencilla, pero siendo algo tan simple, es de gran utilidad según que casos.

VI. Referencias

CSS using PHP

Páginas en varios idiomas

ZoItrix — Sat, 17 May 2008 09:26:49 +0000

I. Introducción

Hace poco he recibido una pregunta en la sección de “Sesiones en PHP“. La pregunta me ha parecido tan interesante que he decidido crear un pequeño artículo explicando su duda e intentando resolverla.

Alguno de vosotros, cuando habéis tenido que crear una página web os habéis encontrado con la necesidad de crearla en diferentes idiomas. Una primera solución, y desde luego no la más eficiente, consiste en crearnos una página por cada uno de los idiomas. Por ejemplo, si tenemos una página “index.php”, si tuvieramos tres idiomas, deberíamos crearnos “index_esp.php”, “index_eng.php” e ”index_ale.php” y cada una escrita en un idioma diferente.

Esta solución, como vosotros podéis ver, es del todo ineficiente. ¡Hagamos un sistema mucho más compacto! Pero… ¿Cómo? Pues la base consiste en el uso de sesiones. Veamos como se hace.

Antes de profundizar en como se desarrollará la aplicación, hay que tener en cuenta todos los elementos que van a formar parte de nuestro sistema:

Una variable de sesión que almacene el idioma.
Tantas páginas web como idiomas haya con la relación de todas las traducciones necesarias. (Esto se puede suplir usando bases de datos).
Un enlace o acceso para que el visitante pueda modificar el idioma.
Funciones que gestionen la petición del usuario a la hora de modificar el idioma.

II. ¿Sesiones? ¿Para qué?

Me imagino que muchos de vosotros pensareis: “¿Para qué narices quiero yo usar sesiones? ¿Qué utilidad tienen aquí?”. Antes de continuar, para el que no sepa muy bien de que van las sesiones le aconsejo que lea mi artículo o al menos revise las referencias que hago en el.

Pues bien, se usarán las sesiones para almacenar en una variable de sesión el idioma que el visitante ha seleccionado. En el caso de no seleccionar ningún idioma, que se le asigne por defecto el que nosotros prefiramos.

Por ello, en todas las páginas de la web deberemos incluir las variables de sesión…

session_start();

session_register(‘idioma_s’);
?>

Esas declaraciones deben encontrarse en todas las páginas donde queramos que se pueda elegir entre varios idiomas. De esta forma tendremos almacenado en todo momento el idioma seleccionado por el visitante y en caso de querer cambiarlo, tener el correspondiente código para hacerlo.

Me explico, el usuario debe ser capaz de poder modificar el idioma en cualquier página web. Cuando lo haga, debe existir un pequeño código que gestione su petición y modifique la variable de sesión a la que el desee.

III. Ficheros de idiomas

¿En qué consiste esto de los ficheros de idiomas? En realidad no es una solución única. Se podría implementar también con bases de datos pero ya que así fue como lo implementé en su momento, se realizará de esta forma.

Consiste en tener tantos ficheros “php” como idiomas haya y en cada uno de estos ficheros incluir una tabla donde se traduzcan todas las frases y palabras de la página web. Un posible esquema podría ser:

$ag = array(
// Título de la pagina:
“titulo_pagina” => “Sessions in PHP”,

// Indice general:
“Indice General” => “Index”,
“Pagina Principal” => “Principal Index”,
…
)

De esta forma, hemos creado una tabla $ag donde, cuando pongamos $ag["titulo_pagina"] hará referencia a lo que está indicado con la flecha. Si lo que está indicado con la flecha está en un determinado idioma, será lo que muestre por pantalla.

Pues bien, habrá tantos ficheros de este tipo como idiomas queramos implementar. Esta sería la parte más laboriosa pues habría que traducir cada una de las palabras de la página web.

Esto añade una pregunta añadida. ¿Cómo escribo yo ahora en las secciones de mi web? Evidentemente ya no se pueden escribir las palabras tal cual sino haciendo referencia a la tabla $ag. Se ve mucho más claro con un ejemplo:

En vez de colocar la palabra “Página principal” hago referencia a la tabla $ag["Pagina Principal"] donde ya se hará la correspondiente traducción. (Recordad, lo que era referenciado por la flecha). Esto habrá que hacerlo para cada una de las palabras que quieran ser traducidas en la página web.

Lo único que habría que hacer ahora para modificar el idioma sería incluir una determinada página u otra en función del idioma que haya seleccionado el visitante. Si se ha seleccionado el español, se hará referencia a la página “es.inc.php”, si se ha seleccionado inglés, se hará referencia a “en.inc.php” y así sucesivamente. Pero… ¿Cómo modifico esas referencias? Es lo que se explica a continuación.

IV. Modificación del idioma

El usuario debe ser capaz de modificar el idioma en cualquier momento de la visita. Por ello, a modo de ejemplo, se podrían colocar tres banderitas (si fuesen tres idiomas) y cada una de ellas que hiciera que se recargara la página enviando una variable GET que fuese la que luego se tratar.

El código podría ser el siguiente:

Idioma:

De esta forma el usuario cada vez que quiera cambiar de idioma lo que se hará será recargar la página donde nos encontremos (tened en cuenta que donde pone “index.php” deberá aparecer la página en cuestión donde estemos). Y se enviará la variable $_GET["lg"] que será la que procesemos. ¿Cómo? A través de un sencillo código:

if($_GET['lg']){
     $HTTP_SESSION_VARS['idioma_s']=$_GET['lg'];
}
$lg=$HTTP_SESSION_VARS['idioma_s'];
if($lg==”es” ||$lg==”en”){
     include($lg.”.inc.php”);
}
else{
     $lg=”es”;include($lg.”.inc.php”);
}

Como se puede observar, en un primer lugar, si se ha solicitado cambio de idioma, es decir, si la variable $_GET["lg"] existe, se modificará la variable de sesión a lo que se haya indicado.

A continuación se le asigna esa variable de sesión a una variable ($lg) y se procesa qué es lo que vale. En función de lo que valga se incluirá una determinada página web u otra. En caso de que no exista $lg, se tomará el idioma por defecto el español tal y como se aprecia en el código.

V. Conclusiones

Siempre que se busque una determinada solución a un problema, en todo momento existirá la solución fácil, la que primero se nos ocurren pero que sin duda, no tiene por qué ser la más compacta. Hay que buscar alternativas más eficientes y escalables de forma que las posteriores modificaciones sean “minucias” comparado con lo que podría haber sido si se hubiera implementado el sistema con fuerza bruta.

Tal y como se puede haber visto, para añadir nuevos idiomas lo único que hay que añadir son tantos ficheros “idioma.enc.php” como hagan falta y modificar la función que procese el cambio de idioma para hacer referencia a un fichero o a otro.

De esta forma, no necesitamos una página para cada idioma sino que con una única página se puede implementar tantos idiomas como deseemos.

Cualquier duda o cualquier aspecto que no se haya entendido correctamente, no dudéis en preguntarlo.

VI. Referencias

CGIs en TOMCAT

ZoItrix — Sun, 24 Feb 2008 19:50:01 +0000

I. Introducción

Debido al proyecto que estoy actualmente desarrollando me he visto en la tesitura de ser capaz de ejecutar CGIs (más concretamente scripts PERL) bajo WINDOWS. Muchos son los manuales que encontré aunque la mayoría no estaban escritos para torpes como yo (y, créanme, ¡las pasé canutas!). Tras estar varios días buscando y buscando logré hacer que funcionaran y me gustaría dejar bien claro qué pasos llevé a cabo para hacer que TOMCAT los ejecutara.

¿Por qué TOMCAT? Seguramente os lo estéis preguntando. Pues bien, me era necesario TOMCAT debido a que necesitaba ejecutar páginas en JSP. Ésto, APACHE no es capaz de ejecutarlos y se requiere de TOMCAT para hacer que funcione.

II. Requisitos previos

Los pasos que a continuación se detallan son comunes a todos los CGIs que se quieran ejecutar en TOMCAT. Pues bien, si quisieramos ejecutar scripts en PERL (que fue con lo que yo me tuve que enfrentar) tenemos que “capacitar” a WINDOWS para que sea capaz de ejecutar scripts en PERL. En caso de no capacitarlo, aunque lo configuremos adecuadamente, cuando queramos ejecutar el fichero .cgi, no lo reconocerá adecuadamente.

Por tanto, si lo que queremos es ejecutar scripts en PERL primero debemos descargarnos la aplicación adecuada para que se puedan ejecutar scripts PERL en WINDOWS. Se puede descargar de aquí.

En el caso de que queramos ejecutar otro lenguaje de programación, será necesario que el sistema operativo sea capaz de interpretarlo. No olvidarlo.

III. Instalación del servidor

Antes de nada, será necesario descargarse JAVA en el ordenador que queramos instalar el servidor. Yo, personalmente, me hago un lío entre JRE, JDK, J2SE, etc. ¡Imaginaos cuando entré en la página de descargas de JAVA! No sabía ni que descargarme. Pues bien, lo que necesitamos es simplemente ejecutar java, no queremos disponer de ningún entorno de desarrollo ni nada por el estilo. Por tanto, lo que os tenéis que descargar en este caso es JRE (Java Runtime Environment) que sirve, simplemente, para ejecutar JAVA en el ordenador. En mi caso me descargué la versión 6. Se puede descargar de aquí. Una vez descargado, lo instalais.

Lo que hay que hacer a continuación es bajarse el servidor TOMCAT. Para ello, el que usé para la instalación fue la versión 5.5. La podéis descargar de aquí.

Una vez descargado, debéis instalarlo. Cuando se está instalando, nos va a pedir donde tenemos instalado el JRE. Normalmente lo detectará solo, si no, hay que seleccionar la carpeta donde se haya instalado (Normalmente está en C:\Archivos de programa\Java\jre1.6.0_01).

Si no tocáis absolutamente nada, el puerto por defecto será el 8080. Es decir, cuando intentemos ejecutar una página web alojada en el ordenador deberemos poner la dirección escuchando en el puerto 8080. Es decir: http://localhost:8080/carpeta_web/index.jsp, por ejemplo.

IV. Visualización web

Antes de continuar, haré un pequeño inciso en donde alojar las páginas web para visualizarlas en el navegador. Yo me llevé un buen rato dándome errores de compilación de java (¡imaginaos la cara que se me ponía!) y era simplemente porque la carpeta estaba mal alojada dentro del servidor.

Pues bien, imaginemos que tenemos una página web alojada en una carpeta. Por ejemplo, la carpeta codigoaldescubierto.

Para alojar adecuadamente esa página dentro del servidor tendremos que entrar dentro de la carpeta asociada a TOMCAT para almacenar las diferentes páginas web. Si no hemos tocado nada cuando hemos instalado TOMCAT, por defecto será: C:\Archivos de programa\Apache Software Foundation\Tomcat 5.5\webapps.

Es decir, dentro de esa carpeta tendremos que copiar la carpeta codigoaldescubierto.

Para acceder a dicha página web, se deberá poner en el navegador lo siguiente: http://localhost:8080/codigoaldescubierto/index.html, por ejemplo.

V. Configuración de TOMCAT

Pues bien, cerremos ese pequeño paréntesis y dediquémonos a intentar configurar TOMCAT para que ejecute CGIs. Lo primero que hay que hacer es detener el servidor en el caso de que estuviera ejecutándose.

Modificación de web.xml

Simplemente debeis acceder al fichero web.xml (Alojado en C:\Archivos de programa\Apache Software Foundation\Tomcat 5.5\conf) y descomentar las siguientes líneas de código:

     cgi
    org.apache.catalina.servlets.CGIServlet

          debug
          0


          cgiPathPrefix
          WEB-INF/cgi

    5

Además, hay que descomentar lo siguiente:

cgi
/cgi-bin/*

Con esto estamos diciendo a TOMCAT que todo lo que alojemos en la carpeta cgi-bin, lo redirecionará a la carpeta cgi que tendremos alojada dentro de WEB-INF (más tarde explicaremos más detalladamente como ejecutar el script).

Creación del fichero JAR

Simplemente debeis renombrar el fichero servlets-cgi.renametojar a servlets-cgi.jar. ¿Dónde está alojado este fichero? Normalmente (para la versión 5.5) está alojado en C:\Archivos de programa\Apache Software Foundation\Tomcat 5.5\server\lib. Si no fuera así, simplemente debéis buscar donde está alojado.

Por último, arrancaremos el servidor que se encontraba detenido. ¡Ya estamos en disposición de probar nuestro primer CGI!

VI. Ejecución de los scripts

Una vez configurado TOMCAT, hay que ver si funciona correctamente. Para ello, lo primero que hay que hacer es distribuir adecuadamente la carpeta donde estará alojada la página web.

Un posible ejemplo de la distribución mínima puede ser (suponiendo que la carpeta es codigoaldescubierto):

codigoaldescubierto/
|__index.jsp
|__WEB-INF/
|__ cgi/
|__script.cgi

La idea es tener dentro de la carpeta cgi todos los scripts que queramos ejecutar. Imaginemos que tenemos un script denominado script.cgi que queremos ejecutar en nuestra página web. Pues bien, para acceder a dicho script, bastará con acceder a la siguiente URL: http://localhost:8080/codigoaldescubierto/cgi-bin/script.cgi

VII. Referencias

Sesiones en PHP

ZoItrix — Fri, 04 Jan 2008 13:08:54 +0000

I. Introducción

¿Qué son las sesiones? Es uno de los sistemas más usados en PHP para el almacenamiento de variables a lo largo de la navegación por una página web son las sesiones.

Consisten básicamente en variables globales que mantienen su valor a pesar de cambiar de sección dentro de una misma web. Recordamos que existen tres formas de almacenar la información de las variables que más tarde querremos procesar:

POST: Envía los datos de forma “oculta” en la cabecera de la página y requiere de un formulario para enviar las variables.
GET: Envía la información en la URL. Tiene la ventaja de poder enlazar directamente con los valores de las variables. Limitación de capacidad y falta de confidencialidad.
SESIONES: Gracias a las sesiones podremos almacenar el valor de variables cuyo contenido se preservará a lo largo de toda la visita.

Un ejemplo de su gran potencial es, por ejemplo, cuando queremos almacenar el nombre de usuario y la contraseña de una persona a lo largo de su recorrido por la web. Podríamos ir enviando dichos valores mediante el método GET pero tanto el nombre de usuario y la contraseña saldrían visibles en la URL destino. Para asegurar confidencialidad y seguridad, se usan las sesiones.

En definitiva, si queremos almacenar valores en unas determinadas variables y que dichos valores permanezcan a lo largo de una visita sin necesidad de ir enviando formularios ni enviando variables por la URL, el método más cómodo son las sesiones. Veamos como se implementan.

II. Implementación práctica

La implementación no debe suponer ningún problema. Hay que tener claro que en cada página donde queramos mantener el valor de dichas variables hay que añadirle las siguientes líneas de código (cuyo significado se explicará detenidamente más adelante):

session_start();

session_register(‘dni_usuario’);
session_register(‘variable_2′);
…
session_register(‘variable_n’);
?>

Es importante añadir que dichas lineas deben estar colocadas al comienzo del fichero HTML. Antes incluso de cualquier etiqueta HTML o código en PHP. Esto es importante pues si no, genera errores.

Como su propia palabra indica, session_start(); indica a la página web en concreto que, en ese fichero HTML queremos usar las variables almacenadas en la sesión.

Posteriormente hay que definir que variables son las que vamos a usar a través de la orden session_register(‘nombre_variable’);

Imaginemos que tenemos tres páginas web:

index.php: Donde colocaremos un formulario de login para el usuario y lugar donde se procesarán los datos introducidos en el formulario.
contenidos.php: De acceso exclusivo a la gente registrada.
noticias.php: Sección que puede tener acceso todo el mundo.

La idea consiste en que, gracias a los datos insertados en la página index.php, el sistema identifique al usuario y le de acceso o no a la página restringida contenidos.php. En el caso de noticias.php no será necesario implementar nada referente a las sesiones pues no se usarán esas variables para procesar absolutamente nada.

En las otras dos páginas (index.php y contenidos.php) será necesario incluir las líneas citadas anteriormente. De esta forma estamos ordenando que dichas páginas “recuperen” el valor de las variables de la sesión para ser usadas en la sección en concreto.

Una vez tenemos dicho a las páginas que vamos a usar las variables de sesión, lo único que queda es saber asignarle valores, quitárselos o recuperarlos. De esta forma, si en la página contenidos debemos verificar si el usuario está registrado o no, podríamos hacer un simple “if” para saber si existe un usuario o no y en caso negativo sacarle el correspondiente error.

Siguiendo con nuestro ejemplo, en index.php y en contenidos.php habrá que colocar las siguientes líneas:

session_start();

session_register(‘nombre_usuario’);
session_register(‘clave_usuario’);
?>

De esta forma se han definido dos variables: nombre_usuario y clave_usuario.

Pues bien, en la página index.php lo que haremos será recoger las variables del formulario en cuestión y almacenarlas en las variables de sesión. En este punto se le pueden añadir tantas restricciones como se quieran. Por ejemplo, comprobar mediante una base de datos que el nombre de usuario y la contraseña corresponden a un usuario registrado con anterioridad. En caso de no existir, denegar la identificación.

if($_POST['login']){
$HTTP_SESSION_VARS['nombre_usuario']=$_POST['nombre_usuario'];
$HTTP_SESSION_VARS['clave_usuario']=$_POST['clave_usuario'];
}

En lugar de escribir $HTTP_SESSION_VARS se puede optar por poner $_SESSION cuyo significado es equivalente. En este caso, escriba lo que escriba, se van a almacenar los valores del formulario dentro de la sesión.

Si existiera un botón de “Desconectar”, se podría poner algo así:

if($_POST['desconectar']){
session_unset();
}

De esta forma, a través de session_unset() lo que se hace es eliminar todas las variables que estuvieran definidas en la sesión. De esta forma, cuando la página web intentara reconocer al usuario, vería que no existe por lo que la desconexión se habría realizado con éxito.

En la página contenidos.php podemos incluir un “if” de forma que si existen las dos variables de sesión, se le de acceso. En caso contrario, mostrarle un mensaje de error. También se podría comprobar si las variables de sesión corresponde a un usuario registrado en una base de datos u operaciones similares.

if(isset($HTTP_SESSION_VARS['nombre_usuario']) && isset($HTTP_SESSION_VARS['clave_usuario'])){
echo “Bievenido a la sección…”;
}
else{
echo “Error: Ha accedido a una sección restringida. Vueva a intentarlo”;
}
?>

Como se puede comprobar, las posibilidades son infinitas. Incluso, si se dispone de un índice, se pueden “anular” accesos en dicho índice comprobando simplemente si el usuario está identificado. Por ejemplo:

Principal

Noticias

?>Contenidos

En este caso, si vamos a usar las variables de sesión en el índice, la sección noticias.php ya si requerirá el uso de las variables de sesión por lo que habrá que incluir las mismas líneas que se incluyeron en las otras dos. Solo en el caso de que el usuario esté identificado, le saldrá en el menú el acceso a la sección contenidos.php.

Todo este ejemplo queda disponible en la parte de “Referencias” para su descarga. En él, se dispondrá del código completo para una mejor interpretación.

III. Funciones

A pesar de la explicación anterior, es importante disponer de una buena referencia de funciones usadas en las sesiones. Entendiendo los fundamentos básicos de las sesiones y sabiendo usar adecuadamente cada función, su uso no debería suponer ningún misterio.

A continuación os comento las funciones más importantes. El resto de funciones podéis encontrarlas en las referencias.

session_start

Inicializa los datos de una determinada sesión. Su uso es imprescindible y se coloca justamente donde se indicó en el anterior apartado: Al comienzo de cada página web que requiera su uso.

session_register

Sirve para declarar las variables que se van a usar en la sesión.

session_destroy

Destruye la sesión actual sin destruir ninguna de las variables. Por ejemplo, si usamos este método únicamente para desconectar a un usuario, no serviría pues las variables asociadas a su identificación seguirían activas. Haría falta borrar dichos valores.

session_unset

Borra las variables asociadas a una sesión eliminando su valor.

IV. Conclusiones

El uso de las sesiones está del todo difundido en las páginas web con un mínimo de programación. Su uso es muy sencillo y da un enorme potencial de trabajo: Identificación de usuario, variables globales de la página o cualquier otro tipo de variable que se quiera almacenar durante todo el recorrido de una página. Incluso se podría ir almacenando el historial de visita de cada usuario de la web.

Las posibilidades son infinitas y su implementación, tal y como habéis visto, bien sencilla.

V. Referencias

Borrar un Directorio

ZoItrix — Sun, 30 Dec 2007 08:19:58 +0000

I. Introducción

Con este artículo no pretendo mostraros ninguna maravilla en programación. Consiste en una función sencilla, muy simple y de fácil implementación que es capaz de borrar un directorio y todos los subdirectorios que existan en ella.

A veces, en muchas de las páginas que se implementan, surge la necesidad de poder borrar un directorio de una determinada carpeta. El problema surge cuando, para borrar un directorio, es necesario antes eliminar todos los ficheros que contenga. Es decir, el directorio debe estar vacío. Ésto puede suponer un quebradero de cabeza si no pensamos las cosas con claridad.

Por ello, y debido a la necesidad que me surgió, implementé una sencilla función (no más de diez líneas) que borrara recursivamente todos los ficheros y subdirectorios dentro de una carpeta.

II. Implementación

El código de la función a implementar es el siguiente:

function borra_carpeta_llena($dir){
     if (is_dir($dir)) {
          if ($gd = opendir($dir)) {
               while (($archivo = readdir($gd)) !== false){
                    if($archivo!=”.” && $archivo != “..”){
                         if(is_dir($dir.”/”.$archivo)){borra_carpeta_llena($dir.”/”.$archivo);rmdir($dir.”/”.$archivo);}
                         else{unlink($dir.”/”.$archivo);}
                    }
               }
               closedir($gd);
          }
     }
}

Pues bien, su explicación es bastante sencilla.

Para empezar, cabe destacar que el parámetro que se le mete a la función es la ruta de directorio que queremos borrar. Me explico, ese directorio es el que vaciaremos pero no se borrará. Si luego queremos borrar dicho directorio también, bastará con poner rmdir($dir) puesto que ese directorio ya se encontrará vacío.

if (is_dir($dir)) {
if ($gd = opendir($dir)) {

Lo primero que hace la función es comprobar que dicho directorio existe y luego intenta abrirlo. Lógicamente, en caso de no poder abrirlo o no existir, saldría de la función sin ningún tipo de problemas. Ésto nos hará evitar posibles errores posteriores.

while (($archivo = readdir($gd)) !== false){
     if($archivo!=”.” && $archivo != “..”){
          if(is_dir($dir.”/”.$archivo)){borra_carpeta_llena($dir.”/”.$archivo);rmdir($dir.”/”.$archivo);}
          else{unlink($dir.”/”.$archivo);}
     }
}

Lo que se hace a continuación es recorrer el directorio en cuestión fichero por fichero. Intento leer un fichero (($archivo = readdir($gd)) !== false) y si lo puedo abrir para leer, entonces prosigo.

En caso afirmativo, debo comprobar que el fichero abierto no sea el de cambio de directorio (es decir, un “.” o los dos “..”). En cuyo caso ya debo verificar si nos encontramos ante un fichero o ante un subdirectorio. Es aquí cuando tomaré las dos posibles decisiones:

if(is_dir($dir.”/”.$archivo)){borra_carpeta_llena($dir.”/”.$archivo);rmdir($dir.”/”.$archivo);}

Si es un directorio, vuelvo a llamar a la función indicándole como ruta del directorio aquella donde se encuentre y a continuación, borro dicho directorio.

else{unlink($dir.”/”.$archivo);}

Si se trata de un fichero, borro directamente dicho fichero.

Como veis, su explicación es bien sencilla pero, simplemente con la llamada a la función ya nos quitamos de ir borrando cada directorio uno por uno.

La llamada a la función sería como sigue:

$dir = “ruta/carpeta/a/borrar”;
borra_carpeta_llena($dir);

Sencillamente eso, sin ningún tipo de historias ni librerías ni nada por el estilo.

III. Referencias

POST y GET

ZoItrix — Thu, 20 Dec 2007 21:42:35 +0000

I. Introducción

En más de una ocasión me han comentado el mismo problema cuando se trabaja con formularios, enlaces y variables en PHP. Consiste, básicamente en que las variables que se envían a través del formulario o las páginas que se acceden enviando los parámetros por la barra de direcciones, luego pierden su valor. Puede llegar a ocasionar pérdidas de tiempo innecesarias que, desde este pequeño manual, intenteremos solventar.

Antes de profundizar en el problema de las “variables perdidas”, voy a explicar brevemente qué es eso de POST y GET cuando trabajamos con PHP, formularios y HTML.

II. POST y GET

Existen tres formas de dar valor a variables en PHP en páginas web. Formularios, enlaces HTML y sesiones. Aquí me limitaré a comentar las dos primeras. La última, se comentará en su debido manual.

Formularios

La primera forma es a través de formularios. Lo habitual es usar el método POST debido a una razón que comentaremos a continuación. Los formularios en cuestión se definen de la siguiente forma:

… ||
…

Con el parámetro method, estamos indicando la forma en la que se enviarán las variables del formulario.

Si tomamos como elección GET, todas las variables se enviarán por la dirección html. Me explico, cuando recarguemos la página web al haber enviado el formulario, saldrá algo así:

http://www.dominio.com/index.php?nombre=Un_nombre&tipo=2…

Es decir, ¡las variables aparecen en la barra de direcciones! Esto, para envío de formularios, no es lo normal pues estamos mostrando todos los datos del envío y pueden ser muchísima información, alguna incluso, confidencial que el usuario no debe enterarse. Es por ello por lo que, cuando tratamos con formularios, usamos el método POST.

Este método consiste, básicamente en enviar las variables de forma “oculta” para que nadie pueda ver los datos que ha enviado al pulsar el botón de envío de formulario.

Enlaces HTML

La segunda forma de enviar las variables es a través de enlaces. Aquí, lo que se hace es enviar las variables mediante el método GET. Más que nada porque cuando escribimos el enlace ya le estamos pasando las variables por la línea de dirección:

Recargar

En este caso, las variables PHP estilo y tipo, se envían usando el método GET. Cuando uno pinche en la palabra recargar, accederá justamente a la dirección marcada y las dos variables aparecerán en la barra de direcciones.

Sesiones

Existe un tercer método de manejo de variables en PHP; las sesiones. Pero este no es el artículo donde procede hablar de ellas.

En definitiva, existen dos formas de tratar las variables (las que vemos aquí) y por tanto, y es a lo que quería llegar: Dos formas de recoger el valor de dichas variables. Veámoslo en detalle.

III. Recogida de valores. Problemática

Tal y como se ha explicado, existen dos formas de enviar las variables:

Con formularios: En este caso, lo normal es usar el método POST.
Con enlaces: Se usará el método GET.

El problema surge debido a que antes, los servidores recogían las variables tal cual. Ésto, produjo que muchos de nosotros nos malacostumbraramos en la “recogida de variables”. Me explico, si cuando uno envía un formulario, declara una variable llamada “nombre”, a la hora de recargar la página, se creaba automáticamente una variable PHP llamada $nombre. De esta forma, la manera de recoger el valor de la variable era bien sencillo. Esto no sucede en la actualidad.

Suponiendo el mismo caso que antes, para recoger los valores de un formulario donde se ha usado el método POST se debe escribir:

$nombre=$_POST['nombre'];

Es decir, si cogemos directamente la variable $nombre, nos encontraremos con que no vale nada. Todas las variables enviadas con el método POST se almacenan en una especie de tabla que se accede tal y como hemos comentado.

Si resulta que la variable se ha enviado usando el método GET o a través de un enlace HTML, habrá que declarar lo siguiente:

$nombre=$_GET['nombre'];

El procedimiento es similar a lo anteriormente comentado.

Os puede parecer algo demasiado obvio, pero realmente puede ocasionar muchos quebraderos de cabeza si sois tan despistados como lo fui yo en su momento.

IV. Referencias

[ESP] Métodos POST y GET en formularios: POST_y_GET
[ESP] POST y GET en desarrolloweb: POST_y_GET
[ESP] Recogida automática de variables POST y GET: POST_y_GET

Select dinámico

ZoItrix — Tue, 18 Dec 2007 13:52:45 +0000

I. Introducción

En el siguiente artículo os muestro como crear un ” dentro de un formulario que, mediante dos “flechitas” puedo ir modificando dinámicamente los campos cambiando el orden de los mismos. El concepto se ve mucho mejor con una imagen:

Como se puede observar, la imagen consta de dos partes:

Un campo .



II. Desarrollo del código

Dividiré la explicación en dos grandes bloques:

Select múltiple

Es importante aplicar a cada un valor. De forma que los valores van asignándose del 0 al máximo del número de campos elegidos.

Por último, cabe destacar que se le ha dado un nombre al           ind=formu.orden_bloque[formu.orden_bloque.selectedIndex].value;
          if(ind>0){
                    nombre_1=formu.orden_bloque[ind].text;
                    nombre_2=formu.orden_bloque[ind-1].text;
                    formu.orden_bloque[ind].text=nombre_2;
                    formu.orden_bloque[ind-1].text=nombre_1;
                    formu.orden_bloque.selectedIndex=ind-1;
          }
“>

La primera flecha se caracteriza por un onclick. Esto quiere decir que cuando nosotros hagamos click en ese botón ocurrirá lo que hemos definido a continuación:

ind=formu.orden_bloque[formu.orden_bloque.selectedIndex].value;

ind indicará el valor de la opción seleccionada. Hacemos referencia al valor value que asignamos cuando creamos el select múltiple. formu es el nombre que se le ha dado al formulario en su declaración:

Antes de continuar, compruebo que ind sea mayor que cero porque si nos encontramos en la opción más baja, si le damos a la flecha de bajar, no debe realizar ninguna acción.

En el caso de que ind sea mayor que cero:

nombre_1=formu.orden_bloque[ind].text;

Asigno el contenido de la opción seleccionada con el select en nombre_1

nombre_2=formu.orden_bloque[ind-1].text;

Asigno el contenido de la opción anterior a la seleccionada con el select en nombre_2

formu.orden_bloque[ind].text=nombre_2;

Indico que la posición actual seleccionada será la anterior a la elegida. Es decir, coloco el nombre_2 donde antes estaba nombre_1.

formu.orden_bloque[ind-1].text=nombre_1;

A la posición anterior a la elegida le asigno el nombre_1. De esta forma, ya he intercambiado los valores.

formu.orden_bloque.selectedIndex=ind-1;

Lo que falta sería marcar como opción seleccionada la que corresponde a nombre_1.

El procedimiento en la flecha contigua sería similar pero considerando que ahora el campo seleccionado lo movemos “hacia abajo”:

>” onclick=”
          ind=formu.orden_bloque[formu.orden_bloque.selectedIndex].value;
          max=document.formu.orden_bloque.length-1;
          if(ind                      nombre_1=formu.orden_bloque[ind].text;
                     nombre_2=formu.orden_bloque[ind-(-1)].text;
                     formu.orden_bloque[ind].text=nombre_2;
                     formu.orden_bloque[ind-(-1)].text=nombre_1;
                     formu.orden_bloque.selectedIndex=ind-(-1);
          }
“>

La primera línea hace lo mismo que con la anterior flecha. Es decir, seleccionar el valor de la opción seleccionada en ese momento:

ind=formu.orden_bloque[formu.orden_bloque.selectedIndex].value;

En ind almacenamos lo ya comentado. Ahora bien, solo se procederá a realizar las operaciones siguientes siempre y cuando no se haya alcanzado el máximo (almacenado en la variable max)

nombre_1=formu.orden_bloque[ind].text;
nombre_2=formu.orden_bloque[ind-(-1)].text;

En realidad hacemos lo mismo que antes pero ahora almacenando en nombre_2 el valor de la siguiente opción a la seleccionada.

formu.orden_bloque[ind].text=nombre_2;
formu.orden_bloque[ind-(-1)].text=nombre_1;
formu.orden_bloque.selectedIndex=ind-(-1);

En este bloque realizamos un procedimiento análogo a lo ya explicado. Cambiamos el contenido en el formulario y hacemos que la opción seleccionada sea la siguiente a la que estaba.



III. Referencias

Descarga ejemplo: Select dinámico

[ESP]Tutorial JavaScript en SELECT

Ventanas emergentes

ZoItrix — Wed, 12 Dec 2007 00:21:34 +0000

I. Introducción

En este artículo pretendo presentar de una forma genérica y de manera muy simple todas las librerías que he logrado encontrar para implementar (mediante AJAX) el uso de ventanas emergentes dentro de una misma página web sin necesidad de abrir más ventanas.

Existen gran variedad de librerías. Realmente todas las librerías realizan más o menos lo mismo pero con pequeñas diferencias.

Básicamente en todas los pasos son los mismos:

Descargar la librería y copiarla en un directorio dentro de la página web.

Realizar las correspondientes referencias en la cabecera.

Crear un enlace de acceso a la web o imagen incluyendo ciertos parámetros.

La gran diferencia estará en que habrá librerías que tengan que implementar códigos javascript dentro de la página HTML, otros que todo se hará a través de referencias en la cabecera, otras librerías que por mucho que se intenta implementar no hay manera de hacerlo, otras que no son compatibles en todos los sistemas de navegación, etc.

El objetivo de este artículo es poder discernir y valorar cada una de ellas viendo cuales ofrecen las mejores garantías. Tened en cuenta que nosotros, cuando buscamos una solución la queremos lo más rápidamente posible y con los mejores resultados. ¿Para qué detenernos en un recurso si para poder ponerlo en funcionamiento hay que llevarse horas y horas teniendo muchas otras alternativas en la web? Hay que ofrecer la mayor simplicidad al usuario y por lo que he podido comprobar, muchas de las librerías que se implementan no están por la labor.

II. Listado de librerías

He dividido el listado de librerías en dos. Un primer listado donde aparecen las librerías que considero realmente útiles y se pueden manejar sin problemas.

Justo a continuación incluyo un segundo listado con el resto de librerías que, o no se adecuan a la sencillez que se requiere de ellas o realmente no las considero de calidad para ser comentada como librería indispensable o sencillamente son modificaciones de librerías ya explicadas por lo que no merecen la pena ser comentadas.

Las librerías de interés general son:

Bride of Windows
Intenta imitar las ventanas de Windows. Permite minimizar la ventana.

GreyBox
Esta librería fue adecuada a mis necesidades. Muestra tanto imágenes como páginas webs.

iBox
Similar a las anteriores. Sirve para mostrar imágenes y páginas web.

ImageBox
Sencilla, útil y práctica. Su única limitación es que solo muestra imágenes.

LightBox
Está limitada al uso de imágenes para mostrar en ventanas.

LiteBox
Muy similar a ImageBox pero sin necesidad de incluir JS en la web HTML. Es una extensión de LightBox pero pesando mucho menos (3KB)

MediaBox
Ofrece la posibilidad de visualizar flash y videos directamente como si de una imagen se tratara. Eso sí, da problema al visualizar imágenes

MoodalBox
Muy sencillo e implementa el efecto de ventana “abriendose” poco a poco.

RoeBox
Mezcla entre LightBox y SlimBox. Fácil uso y sin complicaciónes. Solo muestra imágenes.

subModal
Permite visualizar páginas web. Sencillo uso.

ThickBox
De fácil uso e implementa gran variedad de opciones: imágenes, galerías, páginas webs…

TripTracker
Sirve para mostrar imágenes. Diseño simpático y con posibilidades. Muy sencillo su uso.

A continuación, si tenéis más curiosidad, un listado con el resto de librerías disponibles en la web:

Control.Modal
Ofrece algunas nuevas funcionalidades como que la ventana emergente sea una capa simple de forma que agilice el proceso. Aun así, no la recomiendo pues su uso ofrece muchísimas complicaciones.

Dialog Box
La página en sí es un caos. Lo único que proporciona es que la ventana pueda cambiar de posición en la misma página web.

FlashBox
Muestra las imágenes dentro de un FLASH con sus correspondientes efectos. Únicamente para mostrar imágenes. No funciona bajo internet explorer.

LitBox
Apertura de ventanas movibles.

Prototype Window
En su web comenta que es de fácil uso. Para mí fue imposible implementarla de una forma rápida y sencilla.

RedBox
No ofrece nada nuevo a lo ya comentado. Ventanas muy simples y sin diseño.

SlightBox
Variante de LightBox. Ofrece prácticamente lo mismo. Sólo para mostrar imágenes.

SlimBox
Al igual que el anterior, es otra variante del famoso LightBox.

Sukerfixh HoverLightbox
Variante de LightBox. No he conseguido hacer que funcione ni desde la web propia de la librería.

TinyBox
Librería muy extraña. Me la intenté bajar y resultaba ser un fichero EXE. En fin… Con la cantidad de posibilidades que existen, paso tener que instalar nada.

Para más información, basta con acceder a los enlaces que os he facilitado tanto en la sección en particular de cada librería como en este artículo.

III. Referencias

[ESP] Recopilatorio de Librerías

[ENG] Recopilatorio de Librerías