Ver índice
Páginas WEB dinámicas

        Ocultar índice  

   Índice de contenidos
   Instalación en Windows
   Instalación en Ubuntu
   Servidores seguros
   Páginas dinámicas
   Sintaxis básica
   Operaciones
   Arrays
   Formatos de presentación
   Operadores
   Bucles
   Extraer y ord. información
   Funciones
   Ficheros externos
   Imágenes dinámicas
   Gestión de directorios
   Cookies y sesiones
   Clases y objetos
   Ficheros en formato PDF
   Bases de datos MySQL
   PHP y XML
   PDO - Bases SQLite / MySQL
   MySQL a traves de misqli
   Algo de JavaScript y AJAX


Servidores y clientes

Es frecuente observar, en la calle, que son muchas las personas que cuando se refieren a los servidores lo hacen como sí se tratara de máquinas complejísimas, misteriosas, lejanas y enormes que, bajo esa aureola de cripticismo, parecen totalmente distintas al ordenador que usamos habitualmente. ¡Nada más lejos de la realidad!

Vamos a intentar aclarar algunos conceptos con ejemplos cotidianos. Pensemos en esos ordenadores remotos (también llamados host) como si se tratara de uno esos sitios desde los que se sirven comidas a domicilio.

Quizá lo primero en lo que se te ocurra pensar sea en una pizza, no porque desconozcas que también es posible comprar otras cosas sino por la popularidad de ese tipo de servicio. Algo similar ocurre con los host. La frecuencia con la que accedemos a ellos en demanda de páginas web hace que tendamos a identificarlos con ellas, pero también los host ofrecen –o pueden ofrecer– más servicios. Sigamos con las comidas a domicilio.

Cada una de esas empresas puede atender peticiones de uno solo o de varios servicios distintos (pizzas, helados, o platos regionales, por citar algunos ejemplos), pero la oferta de cada uno de esos servicios requiere una infraestructura adecuada a cada caso. La oferta de pizzas exigirá disponer de un horno, y la de helados necesitará de una instalación frigorífica.

Pues bien, algo muy similar ocurre con los host. También éstos pueden ofrecer uno o varios servicios (páginas web, correo electrónico, transferencias FTP, noticias, etcétera) y también es necesario que cada servicio disponga de su propia infraestructura, que en este caso sería un programa distinto (software de servidor) para cada uno de ellos.

Como puedes ver, no basta con hablar de servidores. Es necesario especificar también qué es lo que sirven.Habría que decir: servidor de páginas web, servidor de correo, etcétera y tener presente que –aunque convivan en la misma máquina– cada uno de ellos requiere su propio software y su propia configuración.

Resumiendo, cuando en lenguaje coloquial hablamos de un servidor estamos aludiendo un host (ordenador remoto) –el tamaño y la lejanía carecen de importancia– provisto de programas (software de servidor) que, cuando está accesible (conectado a Internet) y con el software activo (servidor en funcionamiento) es capaz de atender peticiones y devolver a los clientes los documentos solicitados, o un mensaje de error, en el caso de que no estuvieran disponibles.

Veamos un ejemplo de cómo se desarrolla ese proceso de petición–respuesta. Para leer el correo electrónico necesitas disponer de un programa –supongamos que es Outlook Express– instalado en tu ordenador y hacer, a través de él, una petición a un ordenador remoto (host). Si quisieras visualizar páginas web tendrías que utilizar un programa distinto –Firefox o Internet Explorer, por ejemplo– capaz de realizar esta otra tarea. Al programa que utilizamos para realizar cada petición le llamaremos cliente.

¿Qué es una petición?

Una petición es un conjunto de datos que un cliente (recuerda que el cliente siempre es uno de los programas instalados en tu ordenador) envía a través de Internet solicitando una respuesta determinada por parte de un servidor (ordenador remoto).

¿Qué contendría esa petición?

Cada tipo de petición tendrá contenidos distintos. Por ejemplo, cuando se trata de leer mensajes de correo, la petición realizada por el cliente (Outlook Express) contendría, entre otros, muchos de los datos de la configuración de la cuenta, tales como: el protocolo (forma de comunicación) –en el caso del correo lo habitual sería el protocolo POP (Post Office Protocol)–, el nombre de host donde está alojado el buzón (servidor POP ó servidor de correo entrante), el nombre de la cuenta, la contraseña de acceso, y algunas otras informaciones relativas a la gestión de esa cuenta tales como si deben conservarse o no los mensajes en el servidor, etcétera.

¿Qué ocurre con esa petición?

Cualquier petición pasa en primera instancia por un servidor de nombres de dominio (Domain Name Server) DNS, una especie de guía telefónica que contiene los nombres de los servidores y las direcciones IP a través de las cuales están conectados a Internet. Podría decirnos –los datos son ficticios– que olmo.cnice.mecd.es es el nombre de un host que está conectado a Internet a través de la dirección IP 111.112.113.114

Una vez resuelta esa petición por el servidor DNS (direccionamiento de la petición a la IP correspondiente) se comprobará si esa IP está activa (si efectivamente hay un ordenador conectado a través de ella) y, en caso de estarlo, se determinará si ese ordenador al que estamos accediendo es capaz de atender la petición.

¿Qué tiene que ocurrir para que pueda atenderse una petición?

Es necesario que el ordenador remoto tenga instalado y funcionando el software de servidor adecuado al protocolo de nuestra petición. Ello quiere decir –siguiendo con el ejemplo– que el ordenador remoto debe tener instalado y funcionando un software específico de servidor de correo capaz de interpretar el protocolo POP3 especificado en la petición.

  ¡Cuidado!  

El ordenador remoto debe tener instalado y funcionando el software adecuado a cada tipo de petición (servicio) que deba atender. No basta con decir servidor, es preciso conocer los servicios que presta y es factible que un mismo ordenador preste –simultáneamente– varios servicios, siempre que tenga instalado y activo el software específico para cada uno de esos servicios.


Cuando el ordenador remoto acepta la petición el software de servidor y/o las aplicaciones del lado del servidor (software instalado en el ordenador remoto y vinculado con el software de servidor) resuelven la petición (comprobar que el nombre de la cuenta y la contraseña son correctas, comprobar si existen mensajes, borrarlos del buzón si así lo especifica la petición, etc.) y devuelven al cliente (recuerda que el cliente era nuestro Outlook Express) la información requerida.

Solo falta que una vez recibida la respuesta Outlook Express (cliente) interprete la información recibida y nos permita visualizar o imprimir el contenido de los mensajes descargados del servidor.

Servidor y cliente en una misma máquina

Hasta ahora –al referirnos a servidores y clientes– hemos hecho alusión a dos máquinas: nuestro propio ordenador (ordenador local) en el que estarían instaladas las aplicaciones cliente y un ordenador remoto en el que se alojarían las aplicaciones de servidor. Eso es lo más habitual, pero no es la única posibilidad. Dado que servidor y cliente son únicamente aplicaciones, es perfectamente posible que ambas convivan dentro de la misma máquina.

La diferencia sustancial sería que ahora no es necesario el servidor de DNS para buscar la dirección IP. Utilizaríamos una IP (habitualmente la 127.0.0.1) reservada para estos casos –preestablecida en la configuración del servidor– y a través de ella se canalizarían las peticiones a nuestro propio servidor. Ya hablaremos más adelante de esta IP.

Tipos de páginas web

Una de las clasificaciones más simples de las páginas web permitiría agruparlas en dos tipos: estáticas y dinámicas.

Páginas web estáticas

Diremos que una página web es estática cuando sus contenidos no son susceptibles de ser modificados ni por intervención del usuario ni por una acción automática del servidor (ordenador remoto) ni del cliente (navegador).

Un ejemplo de página estática

Cualquier usuario que acceda a esta página que incluimos como ejemplo –ya sea en modo local, o a través de un servidor remoto– visualizará siempre la misma fecha: 22 de setiembre de 2011.

<html>
<head>
</head>
<body>
Hoy es 22-09-2011 y son las 11:23:37 horas
</body>
</html>
ejemplo1.html

Las peticiones de páginas estáticas se realizan de la forma que puedes ver en este esquema.


Si observas con detenimiento el esquema de la parte superior es posible que encuentres algo que no te cuadre... porque en el esquema hay un servidor que parece imprescindible para atender las peticiones y sin embargo tú –sin tener instalado ningún servidor– eres capaz de visualizar tus propias páginas web sin más hacer un doble clic sobre su icono. Eso es cierto, pero fíjate en las dos direcciones que aparecen en esta otra imagen.


La de la izquierda –consecuencia de haber hecho doble clic sobre el icono del documento– contiene como dirección una ruta (el path que conduce hasta el documento) mientras que en la de la derecha aparece el sintagma http al principio de la dirección.

En el primer caso no hemos hecho ninguna petición de página web sino que hemos abierto un documento cuya extensión (html) está asociada en nuestra configuración de Windows con Firefox, Internet Explorer, Opera o cualquier otro navegador que tengamos instalado en nuestro equipo. El proceso ha sido exactamente el mismo que si hubiéramos hecho doble clic sobre el icono de un documento con extensión txt, con la única salvedad de que en este último caso se habría abierto el bloc de notas (por la asociación de extensiones y aplicaciones en la configuración de Windows).

En el segundo caso las cosas son distintas. Se incluye el sintagma http – acrónimo de HiperText Transfer Protocol– para indicar que ese es el protocolo que debe ser utilizado y que será preciso que el servidor que reciba la petición sea capaz de interpretarlo. Por eso a los servidores que alojan páginas web se les suele llamar servidores web o servidores HTTP dado que se les requiere que soporten este protocolo.

Páginas dinámicas

Llamaremos dinámicas a las páginas cuyos contenidos sí pueden ser modificados –de forma automática o mediante la intervención de un usuario– bien sea desde el cliente y/o desde el servidor.

Para que una modificación de este tipo pueda producirse es necesario que algo o alguien especifique: qué, cómo, cuándo, dónde y de qué forma debe hacerse el cambio, y que exista otro algo o alguien capaz de: acceder, interpretar y realizar, en el momento preciso, las instrucciones de modificación. Igual que ocurre en el contexto de la vida cotidiana, las especificaciones y las instrucciones precisan de un lenguaje para poder definirlas, un soporte para almacenarlas, y un intérprete capaz de ejecutarlas.

Somos capaces de entender unas instrucciones escritas en castellano pero si estuvieran escritas en búlgaro las cosas seguramente serían bastante distintas, y, por supuesto, a un búlgar@ le pasaría justamente lo contrario. Igual ocurre con los programas intérpretes de los lenguajes de script. Ellos también requieren órdenes escritas en su propio idioma.

Scripts

Se llama script a un conjunto de instrucciones, escritas en un lenguaje determinado, que van incrustadas dentro de una página WEB de modo que su intérprete pueda acceder a ellas en el momento en el que se requiera su ejecución.

Cuando se incrustan scripts en una página WEB empiezan a convivir dentro de un mismo documento informaciones destinadas a distintos intérpretes. Por una parte, el código HTML que ha de ser interpretado por el navegador, y por la otra, los scripts que han de ser ejecutados por el intérprete propio del lenguaje en el que hayan sido escritos.

La manera de diferenciar los contenidos es delimitar los scripts marcando su comienzo con una etiqueta de apertura <script> y señalando el final con una etiqueta de cierre </script>.

Lo que no está contenido entre esas etiquetas será considerado código HTML.

La posibilidad de insertar en un mismo documento scripts escritos en distintos lenguajes obliga a especificar cuál se ha utilizado en cada caso, para que en el momento en el que vayan a ser ejecutados se invoque el intérprete adecuado.

Para ello, dentro de la propia etiqueta de apertura (<script>) se inserta una referencia al tipo de lenguaje con esta sintaxis: language="nombre"

Por ejemplo:

          <script language="PHP">
          ......
          ...... instrucciones ..
          ......
          </script>


indicaría que las instrucciones están escritas con la sintaxis de PHP. Por el contrario, al escribir:

          <script language="JavaScript">
          ......
          ...... instrucciones ..
          ......
          </script>


estaríamos señalando que en las instrucciones contenidas en el script utilizan sintaxis de JavaScript. La alternativa más reciente (la anterior está obsoleta) sería:<script type="text/javascript">

Para el caso concreto de PHP, existe una sintaxis alternativa, mucho más cómoda y habitual. Es la siguiente:

          <?php
          ......
          ......instrucciones..
          ......
          ?>


Aquí <?php hará la misma función que <script language="PHP"> y ?> será equivalente a </script>. Con la configuración adecuada también podríamos usar <? –en vez de <?php– como marca inicial.

Lenguajes de script

Hay múltiples posibilidades en cuanto a lenguajes de script. Pero antes de hacer mención a algunos de ellos es conveniente hacer una clasificación previa. Hablaremos de dos tipos:lenguajes del lado del cliente y lenguajes del lado del servidor.

Lenguajes del lado del cliente

Diremos que un lenguaje es del lado del cliente cuando el intérprete que ha de ejecutar sus scripts es accesible desde éste –el cliente– sin que sea necesaria ninguna intervención en este sentido por parte servidor.

Seguramente te ha ocurrido alguna vez que al intentar acceder a una página web ha aparecido un mensaje advirtiendo que para la correcta visualización de la página se requiere un plug-in determinado, y que, a la vez, se te haya ofrecido la posibilidad de descargarlo en ese momento. Eso ocurre porque cuando el navegador –que en el caso de las páginas web es el cliente– trata de interpretar la página, encuentra incrustado en ella algo (un fichero de sonido, una animación Flash, etcétera) que –de forma muy similar a lo que ocurre con los scripts– requiere un intérprete adecuado del que no dispone en ese momento. Cuando los scripts contenidos en un documento son de este tipo, el servidor lo entrega al cliente si efectuar ningún tipo de modificación.

Sin pretender hacer una enumeración exhaustiva, entre los lenguajes de script del lado del cliente los más populares son: DHTML, JavaScript y VBScript.

DHTML no es exactamente un lenguaje de programación. Se trata más bien de una serie de capacidades que se han ido añadiendo a los navegadores modernos mediante las cuales las páginas pueden contener hojas de estilo y/o organizarse en capas susceptibles de ser modificadas, redimensionadas, desplazadas y/o ocultadas.

JavaScript es uno de los lenguajes más populares. Cada navegador incluye su propio intérprete y es frecuente que los resultados de visualización sean algo distintos según el navegador y la versión que se utilice. Parece ser que las versiones más recientes de los distintos navegadores se aproximan a un estándar –ECMA Script-262– que ha sido desarrollado por la ECMA (Asociación Europea de Normalización de Sistemas de Información y Comunicación), lo que hace suponer que en un futuro muy próximo todos los navegadores se ajustarán a esa especificación y que, con ello, las páginas web ya se visualizarán de forma idéntica en todos ellos.

VBScript es un lenguaje de script derivado de VisualBasic y diseñado por Microsoft para Internet Explorer y los navegadores derivados o vinculados a este. Una petición de página en la que hay incrustados scripts escritos en lenguaje del lado del cliente se realizaría de una forma similar a esta:


Como puedes observar no requiere nada distinto a lo del supuesto anterior. La diferencia sería que en este caso se harían llamadas al intérprete de JavaScript –incluido en los navegadores, tal como comentamos al margen– y/o a eventuales plugins necesarios para interpretar otros tipos de script.

Aquí tienes dos ejemplos de páginas web dinámicas. Ambas utilizan los JavaScript que puedes ver en rojo en su código fuente. Si pulsas en el enlace del primero de estos dos ejemplos verás que la fecha que aparece en la página es la fecha actual de tu sistema, y además, cada vez que pulses el botón Actualizar de tu navegador comprobarás que esa intervención del usuario modifica los contenidos actualizando la hora que aparece en el documento.

<html>
<head>
<script type="text/javaScript">
    var son= new Date();
    var fecha=son.getDate()+" - "+(son.getMonth()+1)+" - "+son.getFullYear();
    var hora=son.getHours()+":"+son.getMinutes()+":"+son.getSeconds();
    document.write('Hoy es '+fecha+' y son las '+hora+' horas');
</script>
</head>
<body>
</body>
</html>
ejemplo2.html

En este otro ejemplo la modificación de los contenidos no requiere intervención alguna por parte del usuario. Cada 5 segundos (fíjate donde dice var frecuencia=5000). Cinco mil es el período de actualización, expresado en milisegundos) se rescribirán de forma automática la fecha y la hora. Tenemos por tanto una especie de cronómetro automático.

<html>
<head>
<script type="text/javaScript">
    var reloj=0;
    var frecuencia=5000;
    function actualiza(){
        var son= new Date();
        var fecha=son.getDate()+" - "+(son.getMonth()+1)+" - "+son.getFullYear();
        var hora=son.getHours()+":"+son.getMinutes()+":"+son.getSeconds();
        var escribe='Hoy es '+fecha+' y son las '+hora+' horas';
        var situa=document.getElementById('capa0');
        situa.innerHTML=escribe;
        reloj=setTimeout("actualiza()",frecuencia);
    }
</script>
</head>
<body onLoad="actualiza()";>
<div id="capa0">
</div>
</body>
</html>
ejemplo3.html

Lenguajes del lado del servidor

Un lenguaje es del lado del servidor cuando la ejecución de sus scripts se efectúa, por instancia de este –el servidor–, antes de dar respuesta a la petición, de manera que el cliente no recibe el documento original sino el resultante de esa interpretación previa.

Cuando se usan estos tipos de lenguaje el cliente recibe un documento en el que cada script contenido en el original habrá sido sustituido por los resultados de su ejecución. Esto es algo a tener muy en cuenta, porque, en este caso, los usuarios no tendrán la posibilidad de visualizar el código fuente, mientras que cuando se trata de lenguajes del lado del cliente siempre es posible visualizar los scripts, bien sea de forma directa –mirando el código fuente de la página recibida– o leyendo el contenido de ficheros externos –vinculados a ella– que son bastante fáciles de encontrar en la caché del navegador.  La utilización de este tipo de scripts requiere que el intérprete del lenguaje sea accesible –esté del lado– desde el propio servidor.

Entre los lenguajes del lado del servidor los más populares son: PHP, ASP, PERL y JSP. Cada uno de ellos tiene sus propias peculiaridades. No abundaremos en ellas. Nosotros trataremos aquí sobre PHP.

Las posibles dudas del servidor

Dado que en unos casos el servidor debe entregar el documento original –páginas estáticas o páginas dinámicas en las que se usan lenguajes del lado del cliente– mientras que en otros casos –páginas dinámicas usando lenguajes del lado del servidor– tiene que devolver el resultado de la ejecución de los scripts, es razonable que te preguntes: ¿cómo sabe el servidor lo que debe hacer en cada caso?

La respuesta es simple. Eso hay que decírselo. Y se le dice de una forma bastante simple. Se indica al poner la extensión al documento. Si en la petición se alude a un documento con extensión .htm o .html el servidor entenderá que esa página no requiere la intervención previa de ningún intérprete de su lado y entregará la página tal cual.

Si en esa petición se aludiera a una extensión distinta –.php, por ejemplo– el servidor entendería que antes de servir la página debe leerla y requerir al intérprete de PHP que ejecute los scripts desarrollados en ese lenguaje (en caso de que los contuviera) y devolvería al cliente el documento que resultara de las eventuales ejecuciones de tales scripts.

Aquí tienes el esquema de un ejemplo de convivencia en un mismo documento de varios scripts y varios tipos de lenguaje.



Aquí ya es preciso que, además de un servidor capaz de soportar el protocolo HTTP, esté instalado –del lado del servidor– un intérprete PHP, un servidor de bases de datos MySQL y que, además, estén configurados de modo que puedan interactuar entre ellos.

El lenguaje PHP dispone de funciones que le permiten acceder a muy diversos tipos de servidores de bases de datos pudiendo: crear, consultar, borrar y modificar tanto bases de datos como tablas y registros de las mismas. Nosotros vamos a utilizar MySQL, unos de los gestores más potentes y populares que existen en este momento.

Requisitos para el uso del lenguaje PHP

De acuerdo a lo comentado en los párrafos anteriores el uso del lenguaje PHP requiere tener instalado y configurado: