Wednesday, 3 September 2008

Eventos de teclado con Javascript: onKeyPress, onKeyUp y KeyCode

¿Has necesitado alguna vez controlar con javascript cuándo el visitante de tu web aprieta INTRO cuando está dentro de algún "input" tipo "text", por ejemplo para ejecutar un "submit" del formulario desde javascript en ese momento? La solución es sencilla y pasa por utilizar el evento onKeyPress y la propiedad KeyCode.

Cross-browser y cross-time

Antes que nada, hay que advertir que el mecanismo de hacer esta "captura de
pulsaciones de teclado" ha ido evolucionando al mismo ritmo que han ido evolucionando los diferentes navegadores. Es decir, que si queremos tener un script cross-browser (funcional en "todos" los navegadores), hay que ir con cuidadito y posiblemente el script que utilicemos hoy de aquí a 2 años ya no funcionará en los navegadores más modernos. Creo que es necesario advertirlo porque si uno busca este tema por internet encontrará mil y una soluciones no coincidentes y con resultados distintos. Así que mi consejo es doble: fijaros en la fecha del post y en todo caso, haced vosotros mismos unas cuantas pruebas del script que vayais a implementar ;)

Código HTML


1  <html>
2       <h3>Ejemplo de capturar la pulsacion de INTRO en una caja de texto</h3>
3       <p>Danos tu email:
4       <input type='text' id='email' 
5            onkeypress="javascript:if (getKeyCode(event)==13) alert('Gracias.')" />
6       </p>
7       <script>
8            function getKeyCode(e){
9                 e= (window.event)? event : e;
10                 intKey = (e.keyCode)? e.keyCode: e.charCode;
11                 return intKey;
12            }
13       </script>
14  </html>
Podeis comprobar el funcionamiento de este ejemplo aqui.

Yo he probado que funciona en IE6, IE7, FF2 y FF3, estando a Septiembre de 2008. No puedo comprobarlo en otros navegadores porque no tengo más instalados, pero si alguien lo hace, por favor, comenta aquí tu resultado ;)

Nota: en vuestros comentarios leo que también funciona sin problemas en Opera 9.62

Nota: la sintaxis utilizada en la línea e= (window.event)?event:e; se llama asignación abreviada. Si no las ha utilizado nunca, lee esta breve explicación que acabo de postear.

Ampliación 04-02-2009: onKeyUp

La semana pasada decubrí que se puede usar onKeyUp en lugar de onKeyPress, y ciertamente con mejores resultados. Voy a explicar brevemente la diferencia porque creo que a más de uno le va a interesar.


Obviamente ya sabemos todos los que hemos programado en otros lenguajes que contienen eventos que ambos son muy parecidos. Pero en concreto, me gustó más el resultado obtenido con onKeyUp porque detecta "mejor" el momento en el que los valores de la caja de texto cambian! He rehecho la página de ejemplo para que podáis probar la diferencia.


En donde se aprecia muy bien la diferencia es haciendo lo siguiente: escribimos algo de texto en la caja (probadlo en ambas cajas para ver la diferencia) y el texto se irá "copiando" automaticamente en una etiqueta span que tengamos debajo. Hasta aquí ambos eventos funcionan "aparentemente" igual: cada vez que escribimos una letra, se dispara el evento y replica el contenido de la caja en el span.

Sin embargo, una vez tengais escrito algo de texto, seleccionad parte del texto y pulsad una tecla cualquiera y veréis la diferencia entre ambos eventos: onKeyPress no actualiza el contenido del span, pero onKeyUp sí lo hace!. es decir, sí lo hace, pero solamente si luego seguimos pulsando más teclas, pero no lo hace inmediatamente :(



Jejeje, no me preguntéis el porqué ocurre eso, pero creo que nos es útil saberlo, verdad?! Yo lo descubrí proque estaba haciendo una especie de calculadora de precios: necesitaba que en el span saliera automaticamente el precio con IVA de un precio que yo introducía en un input, y necesitaba que funcionara sincronizadamente (como sucede usando onKeyUp).

Tuesday, 26 August 2008

En PHP recuperar el ultimo ID de un INSERT MySQL

Programando en PHP, ¿alguna vez has necesitado saber el valor generado para un ID autoincremental después de una consulta tipo INSERT? ¿eres de los que -como yo- se ha complicado la vida haciendo una consulta SELECT para encontrar el id más alto en esa tabla o el max(ID)? Pues anota la siguiente instrucción ;)

Te pondré un simple ejemplo de 3 líneas, y verás qué sencillo: supongamos que tienes una tabla llamada 'mi_tabla1' que tiene un campo ID de tipo AUTO_INCREMENT, y necesitas insertar un registro y luego saber inmediatamente cuál es el ID que se ha generado para él, con tal de poder aprovecharlo en otras tablas.

Veamos esas 3 líneas de código:

mysql_query("INSERT mi_tabla1 SET `mi_campo`='mi_valor'");
$ultimo_ID = mysql_insert_id();
mysql_query("INSERT mi_tabla2 SET `id1`='".$ultimo_ID."'");


Breve explicación: en la primera línea insertamos un nuevo registro en la tabla 'mi_tabla1'. En la segunda línea recuperamos CON UNA SOLA INSTRUCCIÓN el último valor "autogenerado" (tiene que haber un campo AUTO_INCREMENT en esa tabla) por la última inserción realizada en la conexión MySQL establecida por el script en ejecución. En la tercera línea utilizamos ese valor para añadir un nuevo registro con ese ID asociado a un campo que esta vez no será AUTO_INCREMENT, pero que permitirá relacionar los registros de ambas tablas.

Cómo habréis notado, el quit de la cuestión está en la función de PHP mysql_insert_id().

Tuesday, 19 February 2008

Cómo evitar que los buscadores indexen nuestras páginas seguras

¿Has incluido páginas SSL seguras en tu sitio web, y los buscadores han empezado a indexarte de nuevo todas tus páginas HTTP como HTTPS, cual duplicados? ¿Sabías que curiosamente eso puede penalizar la posición de tu web en los rankings de esos mismos buscadores?

Como este era mi caso, estuve buscando información para solucionarlo, y aquí os he traducido del inglés un articulo que detalla dos soluciones. El original podéis leerlo en www.seoworkers.com.


Muchos sitios web tienen páginas que utilizan SSL. Esto permite que el intercambio de información entre el servidor y el navegador del visitante suceda en una conexión encriptada, para garantizar la provacidad y la integridad de la misma.

Las URLs (direcciones) de páginas encriptadas con SSL comienzan con https en lugar de con http, para indicar que trabajan sobre un protocolo seguro.

El caso es que si las páginas seguras de tu sitio web han sido indexadas por los buscadores juntamente con el resto de páginas estandar, puedes experimentar serios problemas de canonicalización.


[NT: por ejemplo, que los buscadores consideren que tu página principal sea https://www.midominio.com antes que http://www.midominio.com -tal vez no conteniendo la misma información!!! O también -aún peor- puede que los buscadores interpreten que estás intentando "duplicar" el contenido de tu web con modos fraudulentos, y pueden penalizarte por ello!!! En cualquier caso, es perjudicial para la adecuada presencia de tu web en los buscadores.]

Estos problemas aparecen solo si tienes las páginas seguras dentro del mismo subdominio en el que tienes las páginas estandar.

En cambio, en el caso de que tus páginas seguras las tengas bajo un subdominio exclusivo [NT, por ejemplo: https://pagos.midominio.com] puedes fácilmente excluirlas de la indexación usando el archivo robots.txt en la raíz del directorio de ese subdominio.

En algunos casos solamente una página requiere el uso de SSL (como el formulario de contacto o de pagar). La opción más cómoda y habitual en esos casos es tener esa página siguiendo la estructura estandar del resto del sitio web. Cambiando solamente el "prefijo de protocolo" de la dirección de esa página (de http a https).


Sin embargo, esta técnica es la que nos puede llevar a los problemas de indexación en los buscadores que antes hemos comentado, puesto que los buscadores, si siguen los enlaces que salgan de esa única página SSL, son llevados a "duplicados" de las páginas estandar del sitio, pero con el prefijo https [NT: hay que recalcar aquí que para los buscadores la dirección http://www.midominio.com/servicios.htm es en principio diferente que https://www.midominio.com/servicios.htm, con lo cuál indexará las dos direcciones como páginas diferentes].

Esto sucede porque normalmente todos los enlaces internos dentro de un sitio web son enlaces relativos y por tanto heredan el protocolo y el dominio de la página en donde aparecen.En conclusión, Google -y posiblemente los otros buscadores- pueden considerar esta situación como un intento de "duplicación" de contenidos [NT: técnica que algunos desarrolladores de webs intentan de vez en cuando para engañar a los buscadores, y que por tanto está muy penalizado]. Y esto se traduciría en que los buscadores que quisiseran penalizarte rebajarían la posición de tu página en el ranking páginas en las búsquedas de los internautas.

Una vez indexadas, Google continuará visitando esas páginas seguras de tu sitio, a menos que las excluyas mediante el archivo robots.txt o con meta tags [NT: meta etiquetas] especiales en la cabecera de cada página.


Entonces, ¿cómo puedo evitar que Google visite esas páginas?

Si te encuentras en la posición descrita, te parecerá que no hay manera de solucionarlo fácilmente.

Hay una manera de que el archivo robots.txt redireccione las peticiones de páginas seguras a un segundo archivo que excluiría las páginas seguras a los programas de rastreo.

Para aplicar esta solución, sin embargo, debes usar el servidor Apache en tu hosting con el mod_rewrite activado [NT en inglés "enabled"].

Primero, deberías crear un segundo archivo robots.txt, llamándolo robots_ssl.txt (o el nombre que prefieras), asegurándote de que bloquea a los rastreadores de todos los buscadores. Súbelo a la raíz de tu dominio.

Para más información acerca del archivo robots.txt, qué es y cómo funciona, visita The web Robots Pages [NT: en habla hispana es recomendable WebRecursos - robots.txt].

Aquí tienes un ejemplo de este archivo:


User-agent: Googlebot
Disallow: /

User-agent: *
Disallow: /


Además, necesitarás añadir los siguientes comandos al archivo .htaccess que haya en la raíz de archivos de tu servidor [NT: root document folder]:

RewriteEngine on
Options +FollowSymlinks
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^robots.txt$ robots_ssl.txt

Resumidamente, este comando ordena al servidor web a dirigir cualquier petición para el archivo robots.txt que provenga del puerto 443 (usado para las conexiones SSL, en lugar del puerto 80 habitual para las conexiones web estandar) al segundo archivo que creamos, y que bloquea la indexación.

Para poder comprobar que está funcionando esta técnica, escribe la URL de tu archivo robots.txt en tu navegador para ver el comportamiento habitual del mismo para comandos estandar. Y luego prueba a escribir la misma URL pero con el prefijo de protocolo seguro (https) y deberías ver el contenido del segundo archivo, robots_ssl.txt.

¿Qué puedo hacer si no puedo utilizar mod_rewrite?

Si te es imposible activar mod_rewrite, ya sea porque no utilizas un servidor Apache, o porque no está habilitada esta función, todo lo anterior no te sirve de nada.

Si utilizas PHP para generar las páginas de tu site, puedes utilizarlo para comprobar si se está llamando a tu página mediante SSL, y en caso afirmativo puedes incluir un meta tag en la cabecera [NT: head] de tus documentos para desactivar la indexación por los buscadores.

El siguiente código, situado en cualquier parte de la cabecera de tu documento [NT: entre <head> y </head>] insertará el meta tag robots si el valor de la variable HTTPS del servidor está establecida a 'on':

1  <?php
2  
3       
if (isset($_SERVER['HTTPS']) 
4                 && 
strtolower($_SERVER['HTTPS'])=='on'){
5  
6       echo 
"\n<meta name='robots' content='noindex,nofollow'>";
7  
8       }
9  
10  
?>
Para verificar el funcionamiento correcto de este código, visita cualquier página en la que lo hayas incluido utilizando SSL (https://www.midominio.com/archivo.php). Y luego usa el comando ver codigo fuente de tu navegador para comprobar que el metatag aparece insertado en la cabecera del documento.


Enlaces de interés