09 diciembre 2007

FormMail compat

Y si aún después de todo, tiene problemas en la configuración manual de FormMail y no tiene acceso a usar el script residente en su proveedor de hospedaje, aún puede usar una variación de FormMail, llamado FormMail compat, menos farragoso y más claro que el original. Curiosamente usa la misma sintaxis que correo.pl del que ya hablamos anteriormente y cuyas líneas significativas quedan modificadas de la siguiente forma:

@referers = qw(escueladeartetalavera.com 127.234.112.92 localhost);
@allow_mail_to = qw(info@escueladeartetalavera.com localhost);

y que usted puede modificar con sus datos de dominio, IP y receptores de correo permitidos (pueden habilitarse varios). Observará que las modificaciones son idénticas a lo hecho con el script correo.pl.

Se sube el script, se modifican los permisos a 755, como ya se ha explicado, se modifica ACTION del formulario de forma: http://sudominio.com/cgi-bin/FormMail.pl, (el formulario ha de contener el campo oculto del receptor como ya se explicó anteriormente) y este script no falla.

Puede descargárselo en formato comprimido de la web de la escuela de arte de Talavera en la sección documentos.

Y también puede ver los ejemplos acerca de como usarlo para mandarlo a diferentes destinatarios y redirigirlo a otras cuentas de correo no asociadas al dominio en los documentos de texto adjuntos.

Artículos relacionados:

Gestionar formularios
Formulario básico de correo
scripts CGI. FormMail
scripts CGI. correo.pl

25 noviembre 2007

Formularios con scripts CGI. correo.pl

(Es recomendable haber leído la entrada anterior respecto a FormMail, pues algunas cosas quedan explicadas allí).
Bien, es muy probable que aunque haya seguido los pasos para configurar FormMail este siga sin funcionar, que puede ser debido a múltiples causas, dado que hay muchas versiones y revisiones de este script y además puede haber errores de sintaxis que sean inalcanzables para alguien que no pertenece al mundillo de la informática.
En particular, yo prefiero una variante de este script, desarrollado por Americandominios. Se llama correo.pl y funciona a las mil maravillas. Es más sencillo de analizar. Puede descargarse una versión desde la sección documentos de la web de la escuela de arte de Talavera.
Viene como un fichero comprimido, con el script, con un formulario de ejemplo y con un PDF de ayuda para la configuración.
Esencialmente es parecido a FormMail, ya que está basado en él. Está también escrito en Perl y hay que modificar un par de líneas, como indica la ayuda. Tras subir el script a la carpeta cgi-bin, establecer los permisos y poner la línea en el formulario correspondiente a la acción, es de esperar que todo funcione correctamente.

Así, pues, las líneas modificadas en el fichero correo.pl quedan así:

@referers = qw(escueladeartetalavera.com 137.213.100.76 localhost);
@allow_mail_to = qw(info@escueladeartetalavera.com localhost);

(la ip en este caso es ficticia, debe reemplazarse por la suya como ya se explicó en el artículo anterior)

Y en el formulario, la etiqueta correspondiente quedaría:

[form action="http://www.escueladeartetalavera.com/cgi-bin/correo.pl" method="POST"]

(no olvide sustituir los corchetes si hace copia y pega).

Puede comprobar que funciona magníficamente.

Algunas precisiones respecto al formulario de ejemplo, que puede alterar según su gusto (fíjese al final del código):

[INPUT TYPE=hidden name="env_report" value="HTTP_USER_AGENT,REMOTE_ADDR">
[INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"]
[INPUT TYPE="hidden" NAME="subject" VALUE="Formulario enviado desde escueladeartetalavera.com "]
[INPUT TYPE="hidden" NAME="redirect" VALUE="http://www.escueladeartetalavera.com/confirmacion.htm"]


Fíjese en estos cuatro campos ocultos del formulario: en uno de ellos se establece el informe (report) del formulario. Entre esos datos está el navegador usado para gestionar el correo, así como la IP del que le rellenó el formulario (yo he eliminado el valor REMOTE_HOST, que hace referencia a la página principal de Americandominios).

El campo oculto [INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"] es imprescindible, al igual que en los formularios gestionados por FormMail, para que el formulario sepa donde dirigir el correo. Su contenido debe coincidir con la dirección de correo que se configuró en el script en el apartado @allow_mail_to.

El campo de nombre "subject" hace posible que establezca el asunto del correo. Yo he puesto uno genérico, "Formulario enviado desde ....", si bien puede gestionarse uno distinto con un campo de texto de entrada en el formulario, que se llame "subject" y donde el usuario pueda establecer su Asunto personalizado.
Y por último, se establece en el campo "redirect" dónde debe acabar el usuario tras haber mandado el formulario. Yo lo configuro a una página donde se confirma que se ha recibido el formulario correctamente pero que tiene el mismo aspecto de la página donde se rellenó, para que el usuario pueda seguir navegando desde el punto en que decidió mandar su consulta.

Todo esto puede verlo en acción desde la página contacto de la web de la escuela de arte de Talavera, donde además puede apreciar el diseño de campos y botones personalizados aplicando hojas de estilo CSS corrientes y molientes.

Por cierto, si observa, puede acceder a otro formulario de contactar con el webmaster. Sepa que el formulario de la consulta genérica está gestionado por el script correo.pl configurado manualmente y que el formulario de contacto con el webmaster usa el script FormMail. Puede comprobar que ambos funcionan sin problemas.

Artículos relacionados:

Gestionar formularios
Formulario básico de correo
scripts CGI. FormMail
FormMail compat

Formularios con scripts CGI. FormMail

Si lo que desea es un formulario que funcione de forma transparente al usuario, puede usar el método clásico de utilizar los scripts CGI. Con ellos, el usuario de su formulario, no tiene más que rellenarlos, pulsar el botón "Enviar" y nada más. Usted recibirá en su correo los datos que hayan sido completados.
Los scripts CGI son archivos escritos normalmente en lenguaje Perl y de los que gestionan el uso de formularios el más famoso es FormMail. Es un recurso tipo Open Source, desarrollado por Matt Wright, gratuito y de código abierto. Es el más usado universalmente.
Puede descargarlo de las múltiples páginas que lo ofrecen en internet, o bien desde el enlace en la escuela de arte de Talavera, en la sección documentos. Se ofrece como archivo comprimido, con un fichero de texto adicional de instrucciones (en inglés).
También se ha de comprobar con el servidor si éste da soporte para scripts CGI (los gratuitos no suelen). Con los servicios de hospedaje de pago es habitual que sí lo hagan. Si no lo hacen, ya sabe el camino que debe tomar cuando toque renovar el servicio.
Por lo general, si no quiere complicarse la vida configurando el FormMail, diríjase a su proveedor de servicios de hospedaje y hágale la consulta directamente, de cuál es la dirección en donde reside FormMail en su servidor. Le dirán qué debe poner en el campo Acción de su formulario y ya está. Suelen funcionar sin problemas.
Por el contrario, si su servicio de hospedaje no tiene un script tipo FormMail configurado para sus clientes, debe realizar sus operaciones a mano del modo en que se describe a continuación.
A través de su programa de FTP (yo recomiendo fervientemente no usar uno de terceros si edita con Dreamweaver, use directamente el propio DW para comprobar el estado de su sitio y su sincronización con los datos remotos), compruebe si hay una carpeta llamada cgi-bin en su servidor. Si no la tiene, puede crearla usted mismo y aquí es donde hay un punto de discordia entre los diferentes proveedores de servicio: ¿dónde crear la carpeta?
Habitualmente las páginas se publican en una carpeta llamada html_public o httpdocs o algo por el estilo. Pues bien, dependiendo de como traten los contenidos de su web, habitualmente la carpeta cgi-bin está por encima de la mencionada. Ahí es donde debe alojar el script o mirar si ya se la proporciona el proveedor, fuera de la pública. Si no tiene asignada una estructura de carpetas por el proveedor, puede probar a crearla dentro de la que aloja su sitio web completo. Esto afecta a la ruta que debe indicar en su formulario para ser procesado.
Debe modificar el FormMail con un editor de texto tipo Bloc de Notas (Notepad) o WordPad, desaconsejándose que se use un procesador de textos de los que guardan el texto con formato, pues no funcionará. El fichero ha de ser ASCII y el resultado de guardado posterior ha de ser FormMail.pl, aunque puede usarse otro nombre siempre que después lo indique en la acción de su formulario.

Las modificaciones esenciales de FormMail son las siguientes:

@referers = ('midominio.com','ip del servidor');

en su domino, debe poner el propio, por ejemplo 'escueladeartetalavera.com' y después la ip del servidor donde está alojada su web. Esta información puede obtenerla de los detalles del contrato con su proveedor de servicios, o del panel de control que suele asignarse a los clientes y donde se encuentran los datos referentes a su cuenta. Si no lo encuentra, puede dirigirse al proveedor de hospedaje para que se lo proporcione.

@recipients = ('midominio.com','usuario@midominio.com');

Aquí se indica el destinatario del correo que recibe los datos del formulario. Tiene la restricción que debe ser una cuenta de correo asociada a su dominio, no una dirección de correo cualquiera, porque FormMail hace referencia a los servidores de correo asociados con midominio.com. Cuestión distinta es si usted puede y quiere redirigir los mensajes que reciba en esa dirección a otra de su conveniencia, aunque en cuestiones de correo, yo prefiero no mezclar unos asuntos con otros. Razón de más para usar varias cuentas de correo y gestionarlas todas separadas, pero al mismo tiempo, con un programa como Outlook, pero esa es otra cuestión.

Para la web de la escuela de arte sería algo así:

@referers = ('escueladeartetalavera.com','192.43.132.56');
@recipients = ('escueladeartetalavera.com','info@escueladeartetalavera.com');

(la ip es ficticia)

Con estas modificaciones básicas, por el momento basta. No se abrume con el contenido del resto del script.

Una vez modificado, súbalo a su servidor por el método habitual, a la carpeta cgi-bin anterior.
Ahora hay que darle permisos al script, los llamados permisos CHMOD de lectura/escritura. Puede hacerlo directamente con Dreamweaver (¿no es maravilloso?), pulsando con el botón derecho sobre el fichero remoto alojado en el servidor (debe estar conectado) y en el menú contextual "Establecer permisos". Básicamente se permite al autor poder leer/escribir/ejecutar el script y a los usuarios, permitirles ejecutarlo solamente. Las diferentes opciones escogidas producen un valor total del permiso, pero usted puede limitarse a escribir 755 en el valor total.
No olvide comprobar que el valor total es 755 tanto para el script como para la carpeta donde se aloja.

Y, en el formulario, en la Acción, desde el inspector de propiedades de DW se pondría:

http://www.escueladeartetalavera.com/cgi-bin/FormMail.pl
El formulario ha de contener de modo imprescindible un campo oculto de tipo
[INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"] donde el valor recipient ha de coincidir con la dirección de correo definida en el script.

Puede también probar a usar otros nombres del formmail si tiene problemas con las mayúsculas, siempre que lo indique en la acción del formulario.

El método como en el caso anterior, es POST.

El resultado es que cuando el usuario pulsa el botón enviar, el formulario se remite al archivo FormMail, que se encuentra ubicado en la carpeta cgi-bin. Este procesa la información y manda el resultado a la dirección de correo que se encuentra en el @recipient.

Pueden hacerse más modificaciones en el script, pero para lo que nos proponíamos, esto basta.

Puede consultar también otros tutoriales de internet, como éste, por si se entera mejor.

Pero desde este momento le indicamos que hay más consultas en internet respecto a como se configura y problemas insolubles, que a consejos útiles para que funcione debidamente. Creo que es por causa de que hay varias revisiones de FormMail funcionando y hay que leerse el manual adjunto (en inglés), lo que no siempre es fácil. Mi experiencia me dice que la mayor parte de problemas provienen de detalles absurdos, como el establecimiento de permisos o de la sintaxis empleada en el campo @recipients.
Si no ha sido capaz de hacer que funcionen de ninguna de las dos maneras, no desespere, porque le propongo dos métodos más: lea los artículos de correo.pl y FormMail compat.

Artículos relacionados:

Gestionar formularios
Formulario básico de correo
scripts CGI. correo.pl
FormMail compat

24 noviembre 2007

Formulario básico de correo

Daremos por sentado que se saben hacer formularios. Lo que es un campo de texto y demás. Aquí nos ocupamos de que funcionen.
La primera opción y más económica es recibir un correo en texto sin formato lo que se logra haciendo que la línea correspondiente a la "Acción" del formulario sea eso, enviar un correo. Por ejemplo: (sustituya los corchetes por <>)
[form action="mailto:javieranquela@gmail.com" method="POST"]
Si usa un editor de páginas tipo Dreamweaver, puede hacerlo en el inspector de propiedades. Seleccione el formulario (o su etiqueta form) y en el campo Acción escriba como si fuera un vínculo de correo electrónico mailto: sudirección@decorreo.com, donde ha de escribirse en esta dirección aquella en la que queremos recibir el contenido del dichoso formulario.

Habrá observado que el método elegido es POST y no GET, usándose este otro método, por ejemplo, en otras operaciones distintas, como es el de envío de valores de variables PHP con las direcciones de las páginas en sus URL, pero eso es harina de otro costal. Usted limítese al método POST.

Pero así solo no funcionará, por el tipo de codificación. En el método de codificación hay que escribir, (porque Dreamweaver por ejemplo no lo tiene entre sus opciones), text/plain y no otros tipos como el multipart/form-data o el application. Este es el punto clave para hacer que el correo funcione.
El usuario de su web que rellene el formulario, cuando le de al botón de enviar, verá, con sorpresa para muchos, que se confirma que se está enviando información desde el equipo y le pedirá que confirme el envío del contenido del formulario.
Este es el verdadero problema de este método y es que no está generalizado el uso de programas clientes de correo del tipo Outlook entre los usuarios de internet.

Si un usuario no tiene una cuenta de correo configurada en su Outlook, no podrá mandar el correo y si no sabe que habitualmente el mandar los correos no se hace de forma inmediata, sino que tiene que revisar si el correo ha salido de su Bandeja de Salida, peor que peor. Los más avispados podrán al menos abrir el correo y copiar la dirección del destinatario y mandar un correo vía web a mano. Pero para ese viaje no necesitábamos alforjas.

Supongamos que damos con alguien un poco espabilado, que tiene una cuenta de correo configurada en su Outlook. Lo que usted, como receptor del correo, recibirá será el nombre de los campos del formulario, se hayan rellenado o no, el contenido que haya puesto el usuario (incluso recibirá hasta los botones tipo "Submit") y por supuesto, si sabe manejarse con campos ocultos de formulario, el contenido de estos campos.
Todo ello como un mensaje legible de correo en texto sin formato, no como datos adjuntos. Como vendrá como un correo del usuario, tendrá también a disposición la dirección de email del que se lo mandó con lo que podrá responderle.
Y con esos datos puede hacer lo que quiera, eso sí, a mano.

Artículos relacionados:

Gestionar formularios
scripts CGI. FormMail
scripts CGI. correo.pl
FormMail compat

Gestionar formularios

Una de las frustraciones habituales con las que se encuentra un diseñador es cuando se enfrenta con un formulario y se las promete tan felices al respecto, de cómo recibirá comentarios, mensajes y sugerencias a través de la web. Y de pronto se encuentra con que los manuales de los programas de diseño (algunos no muy al día), en el mejor de los casos te enseñan a diseñarlos. Para la gestión, recurren a la consabida coletilla: "No es el objeto de esta obra el explicar como se gestiona un formulario; para más información, acuda a obras especializadas".
Que es tanto como decir que un diseñador debe limitarse a eso, a diseñar y que las tareas de gestión de formularios (y no digamos ya de bases de datos) es propia de otro departamento, el de informática.
¿Y si en mi empresa el que más sabe de informática soy yo (entre otras cosas porque soy el único dueño y empleado, por ejemplo)?
Con lo fácil que sería dar algunas pequeñas indicaciones. Tampoco es que el manejo de formularios para que funcionen, se rellenen, vayan y confirmen sea para mentes privilegiadas. Es, como todo, simplemente saberlo hacer.
Dedicaremos unos cuantos artículos a este tema.
En primer lugar, debe decidir qué pretende hacer con su formulario. Porque una cosa es recibir una sugerencia, una petición de contacto, etc. Y otra muy distinta recibir por la vía de un formulario una cantidad de datos con la finalidad de dar de alta a un usuario en un servicio o una petición de comercio en línea, como los de carritos de la compra.
En el primer caso, un mensaje de correo basta. Es decir, si queremos recibir una petición de información respecto a nuestros productos, una solicitud de contacto, una sugerencia, probablemente nos conformemos con recibir un correo electrónico donde el nombre del remitente, su email y su mensaje sean suficientes.
En el segundo caso, si queremos inscribir a un nuevo usuario en nuestro portal, aceptarle una contraseña, darle un servicio de correo, un catálogo en línea, cobrar un pedido a través de una pasarela, o mostrar unos movimientos bancarios, eso ya son palabras mayores: el destino del formulario no puede ser un simple correo, ha de ser una base de datos en la que se ingresen los datos rellenados.
Para el primer caso (destino correo), pueden usarse varios métodos, algunos realmente sencillos, bien directamente o bien a través de los scripts CGI (el más famoso, FormMail). En el segundo caso, se requiere habitualmente un lenguaje de comportamientos de servidor, tipo PHP, ASP, JSP o Cold Fusion, además de destreza en el uso y manejo de bases de datos tipo MySQL. Lo que no quiere decir que con PHP por ejemplo no se puedan solucionar formularios cuyo destino es un fichero de texto cualquiera, que también para eso sirve.
Quizás más adelante dediquemos unos artículos a estos y la integración con bases de datos. Pero por el momento nos centraremos en la cuestión más básica, aquella en la que un usuario se dice: soy usuario de HTML de toda la vida, ni sé PHP ni usar un servidor de correo, ni ganas; sé hacer un formulario y sólo quiero hacer que funcione, que alguien pueda escribir un mensaje, le de al botón "Enviar" y pueda recibirlo claramente.
De eso nos ocuparemos a continuación.

Artículos relacionados:

Formulario básico de correo
scripts CGI. FormMail
scripts CGI. correo.pl
FormMail compat

23 noviembre 2007

Video embebido

Podemos hacer un "embebido" del video directamente, de un video que se encuentra en una determinada dirección, con la etiqueta embed , que es la forma más económica de hacerlo. Este video ha de estar en línea y puede encontrarse en cualquier dirección de internet, solo hay que conocer su ubicación. Por ejemplo, en el caso de abajo, el código sería:

[embed src="http://video.google.com/googleplayer.swf?docId=9140752344761227618&hl=es"][/embed]

Desde Google Video

Desde el servicio de Google Video es semejante a Youtube. A ambos servicios puede accederse con una cuenta de Google-Gmail y su uso es semejante.
Se suben los videos a la cuenta respectiva en los formatos admitidos: *.mov, *.avi, *.mpg, etc. y tras el procesamiento, se busca el código HTML para ser insertado en la entrada del Blog.

Nótese en el caso de abajo una variante y es que la reproducción de video se logra automáticamente al cargar la página sin necesidad de pulsar el botón de "Play", simplemente añadiendo en el código el parámetro flashvars="autoPlay=true".

En todos estos casos, el vídeo va incrustado en un reproductor Flash que es generado por Youtube o Google Video.

Por ejemplo:

Subir video directo

Por el contrario, puede subirse directamente un video a Blogger con el botón "Añadir video" en la edición de entradas. En este caso, el resultado es distinto, así como el código generado. En cualquier caso, ya sea con Youtube (o para usuarios de Google Video), se ha de esperar un cierto tiempo entre la subida de video y su visualización, tiempo durante el cual el servicio correspondiente se dedica a procesar el mencionado clip.

Poner video desde Youtube

El vídeo que se reproduce a continuación se descarga directamente desde Youtube, que lo inserta en un reproductor Flash. Se copia el código y se pega en la entrada directamente. Puede personalizarse la apariencia del reproductor y también su tamaño como puede verse en el ejemplo siguiente, manipulando los atributos width y height. Es conveniente mantener la relación de aspecto.



19 noviembre 2007

Algunas mejoras sobre los feeds

Creo que ya expliqué que una de las tareas imprescindibles respecto a los feeds RSS es la de validarlos, ya que es muy frecuente que estos tengan algún error. Hay muchos servicios que pueden usarse para ello, pero yo uso Feed Validator, que te da indicaciones acerca de errores de código y sugerencias para mejorar.
Una de las mejoras sugeridas en uno de mis antiguos feeds es la inclusión de líneas que hacen del Feed compatible con XML y con Atom.
De igual forma, sugiere que haya una línea que haga referencia al propio feed dentro de la etiqueta channel.
A modo de ejemplo, el comienzo de uno de mis antiguos feeds (ya validado y probado su uso) queda de la siguiente forma (solo se muestra un item):

[?xml version="1.0" encoding="utf-8"?]

[rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"]
[channel]
[title]Escuela de Arte de Talavera[/title]
[link]http://www.escueladeartetalavera.com/[/link]
[description]Sitio oficial de la escuela de arte de Talavera[/description]
[language]es[/language]
[lastBuildDate]Mon, 19 Nov 2007 00:00:00 GMT[/lastBuildDate]
[atom:link href="http://www.escueladeartetalavera.com/rss.xml" rel="self" type="application/rss+xml" /]


[item]
[title]Premios II Maratón fotográfico Ciudad de Talavera[/title]
[pubDate]Mon, 19 Nov 2007 00:00:00 GMT[/pubDate]
[guid]http://www.escueladeartetalavera.com/maraton_2007/galeriamaraton2007.htm[/guid]
[description]Premios de la II edición del maratón fotográfico Ciudad de Talavera, organizado por la asociación cultural Taboracrom y patrocinado por el Ayuntamiento de Talavera de la Reina.[/description]
[/item]
[/channel]
[/rss]


Obsérvense las líneas resaltadas, donde no solo se hace mención a la ubicación del feed propio (en mi caso, se llama rss.xml) sino también a la fecha de última creación del feed y la de publicación de los items, información también útil.
Se sigue el convencionalismo habitual en este blog de que hay que sustituir los corchetes por los símbolos <>.

16 noviembre 2007

Premios Taboracrom

Se han fallado los premios de Taboracrom de fotografía y la obra se encuentra expuesta en la escuela de arte de Talavera durante este mes de noviembre y diciembre. Se cumplen así 11 años ya de estos premios y además se presenta por segunda vez una edición del Maratón fotográfico "Ciudad de Talavera", celebrado durante el pasado 12 de octubre y en el que se puede participar con cámara fotográfica o bien con el mismísimo teléfono móvil, con lo que la participación juvenil está asegurada.
Puede ampliarse esta informaciónaquí

Algunas muestras de las obras premiadas:


13 abril 2007

Publicar Flash en Blogger



Bien, supongo que sería interesante copiar el código para insertar una película Flash en una entrada del blog. El trozo de código correspondiente a la anterior es como sigue:
[embed pluginspage="http://www.macromedia.com/go/getflashplayer/" src="http://www.escueladeartetalavera.com/flash/introbis.swf" width="600" height="120" type="application/x-shockwave-flash" quality="high" menu="false" bgcolor="#000033"][/embed]

donde evidentemente las etiquetas embed no van entre corchetes sino entre <> (se ha escrito mal a propósito para evitar que la entrada entienda el código y muestre la película de nuevo repetida.
En este código se debe sustituir el nombre del fichero Flash por el que corresponda, con su ruta completa y desde luego ha de ser un fichero en línea, esto es, alojado en un servidor.
Nótense los atributos acerca del ancho y del alto y también mencionar que al incrustarse a través de la etiqueta "embed" es inevitable que aparezca el mensaje del pulsar para activar el control, típico de este tipo de ficheros.

Nótense además dos detalles: cómo la película Flash soporta un vínculo a un sitio externo al blog y cómo ese vínculo se abre en ventana nueva. Todo eso está hecho en la película original, evidentemente.

07 abril 2007

Web en Joomla!

Un nuevo proyecto web de la escuela de arte de Talavera. A su sitio oficial, a los trabajos de los alumnos y ex alumnos, con harto mérito por su parte en tantos casos, a los blogs de alumnos y profesores,... se suma ahora el proyecto de una nueva web basada en Joomla!, el gestor de contenidos o CMS de moda.
Aunque aún está menos que verde, los dotados de esa sana curiosidad morbosa pueden visitarla en el enlace que ofrecemos:
escuela de arte de talavera

06 abril 2007

robots.txt

El fichero robots.txt puede llegar a ser de utilidad en un sitio web y generalmente está disponible en modo automático en los gestores de contenido, que ya te lo dan escrito y optimizado, si bien puede ser modificado.
Cuando uno se lo quiera hacer a mano, debe saber qué es, para qué sirve y como se optimiza.
En esencia es un fichero de texto plano, o texto sin formato, editado con un editor tipo bloc de notas (Notepad) que tiene una serie de órdenes para comunicarse con los robots que rastrean e indexan una web para ser incluidas en sus correspondientes directorios de los buscadores a los que sirven.
En realidad, cuando un robot o un spider llega a una web, lo primero que busca es la existencia de este fichero robots.txt (eso dicen), que le da instrucciones acerca de los permisos y prohibiciones que se le dan para rastrear archivos y carpetas.
Esencialmente hay dos tipos de instrucciones:
User-agent: para referirse a un robot en particular.
Disallow: para deshabilitar el permiso de una carpeta en particular.

Será que como son robots, su lenguaje es bastante reducido y se limita a buscar aparcamiento y pedir café con leche, que es lo esencial en la vida moderna.

Además se usa el caracter comodín * para hacer referencia a todos los robots o a todas las carpetas, con la misma convención que viene usándose desde el viejo Ms-DOS. (¡quién se acuerda ya del pobre!).

Pongamos por ejemplo que queremos deshabilitar el que un robot rastree determinadas carpetas, denominadas por ejemplo flash (donde se encuentran nuestros archivos Flash), dado que no sé si saben que Google, por ejemplo, indexa las películas Flash (*.swf) publicadas en un sitio web como ficheros adjuntos (resultados suplementarios, los llama) y eso supone tiempo de rastreo.
O, por ejemplo que tenemos una carpeta de pruebas, llamada pruebas o algo más inteligente, o una carpeta con notas de diseño, llamada notes, u otra con nuestros scripts CGI llamada cgi-bin, u otra llamada scripts, etc.
Revisar por un robot todas esas carpetas se traduce en tiempo y en cabreos del robot, ya que la dedicación que nos da a revisar nuestro website es limitada y no conviene marearlos, que son muy sensibles a las pérdidas de tiempo, que tienen varios millones de webs en cola de espera.
Otra técnica que puede usarse es la de que no vuelva a pasar por una carpeta cuyo contenido principal sabemos que ya está indexado en el directorio del buscador correspondiente, modificando periódicamente el robots.txt para hacerle que vaya a nuevas carpetas aún no revisadas y deshabilitando las ya miradas y remiradas por un periodo largo de tiempo.
Un posible fichero robots.txt con estas finalidades podría ser de la siguiente forma:

User-agent: *
Disallow :/cgi-bin/
Disallow :/bin/
Disallow :/conf/
Disallow :/flash/
Disallow :/error_docs/
Disallow :/Scripts/
Disallow :/_private/
Disallow :/pruebas/
Disallow :/templates/

etc.

Con esto le estamos hablando a cualquier robot y le prohibimos que revise las carpetas mencionadas, para que no invierta tiempo en contenidos irrelevantes para él.

También podemos hablarle a cada robot en particular, solo debemos saber como se llama, por ejemplo, el de Google tiene dos, el Googlebot que es el genérico y el Googlebot-Image, que es el utilizado para incluir imágenes en su directorio. El de Altavista se llama Scooter, etc. Así podríamos ir añadiendo bloques de texto como el anterior habilitando y deshabilitando carpetas, según los contenidos que vayamos viendo que están indexados en los diferentes directorios de los múltiples buscadores.

p. ej:

User-agent: Googlebot
Disallow :/cgi-bin/
Disallow :/bin/
Disallow :/conf/

User-agent: Googlebot-Image
Disallow :/cgi-bin/
Disallow :/bin/
Disallow :/conf/

User-agent: Scooter
Disallow :/cgi-bin/
Disallow :/bin/
Disallow :/images/

¿Qué finalidad puede tener esto? Con el asterisco como comodín podríamos haberlo hecho para todos. Yo le encuentro dos: la primera porque no todos los robots indexan e incluyen las páginas de forma igualitaria y puede que ya tengamos contenidos en ciertos directorios y en otros no, que nos interesa poner a disposición de unos y de otros ya no sea necesario. En segundo lugar, lo que yo llamo el efecto sicológico de las fuerzas irracionales de la informática, dado que con decir "Españoles todos: bla, bla, bla,...", quedamos todos los españoles incluidos en el llamamiento, pero no es lo mismo que el que nos fueran llamando a cada uno por nuestro nombre. Supongo que es más directo y cortés llamar a los robots de nuestro interés por su nombre directo que de una forma genérica. Una locura inútil como otra cualquiera.

Por último, el fichero ha de ser publicado en el directorio raiz del sitio web, en el más alto al que tengamos acceso. Pero seguro que ustedes pueden encontrar fácilmente en internet opiniones más precisas que las mías y, seguramente, más altamente especializadas. No obstante, le doy el consejo que no se me pide: desconfíe de las leyendas urbanas y sólo crea de lo que se dice en internet y en sus foros aquello que usted haya comprobado por sí mismo con sus experiencias y experimentos.

Becas, empleo y premios de diseño

El centro de diseño de Castilla la Mancha publica en su web las convocatorias de becas para diseñadores emprendedores de esta región, las ofertas de trabajo para diseño y webmasters de las que tiene constancia en su base de datos y la nueva edición de los premios de diseño de Castilla la Mancha para diseñadores y empresas con amplia trayectoria. Puede consultarse esta información en la web de la escuela de arte de Talavera, en su sección de noticias del mes de abril.

Para enterarse

17 marzo 2007

artclan

Se han añadido a los enlaces recomendados de este blog las páginas web de los estudios de diseño de antiguos alumnos de la escuela de arte; en concreto, de spacio2, erreQerre y de artclan. De avisos en primicias, este último, formado por los antiguos alumnos de gráfica publicitaria Iván Cano y José Ángel Ruiz que presentan la novedad de su mejor cara en internet. Altísimamente recomendable para todos los amantes del buen gusto y los resultados cardíacamente espectaculares. http://www.artclan.com/
Exalumnos como estos y tantos otros son los que justifican el que uno se dedique a esta profesión en los tiempos que corren. Un placer, un privilegio y un honor.

08 marzo 2007

Feeds en Blogger

En Blogger, los feeds al menos tienen dos finalidades. En primer lugar puede dejar que su blog genere su propia fuente si así lo configura en las Opciones, en la categoría Feed del sitio. Pueden mostrarse las entradas de forma completa o en modo corto o abreviado. Cuando se accede a un blog que genera su propio feed, puede verse éste pulsando sobre el susodicho botón naranja de los exploradores mencionados (en Explorer, a partir de la versión 7). También puede, como con cualquier otra fuente, una vez que está viéndola, suscribirse desde el propio explorador y tener acceso a las novedades en la barra vertical de la estrella amarilla, donde se concentran los favoritos, las fuentes a las que uno está suscrito y el historial.
Por otro lado, en un blog se puede agregar como contenido extra los feeds de nuestros sitios favoritos, para que muestren noticias. Se hace desde el panel de diseño, en "Añadir un elemento a esta página", eligiendo el feed y poniendo la dirección de internet del fichero que pretenemos mostrar en nuestro propio blog. Por ejemplo, la fuente de nuestra página web personal. Tiene el inconveniente de que solo se pueden mostrar cinco items de dicha fuente y su actualización automática como que no está muy claro, si sufre cambios o novedades.
Es aconsejable hacer una fuente ex profeso para añadirla a Blogger con no más de 5 items. Si tiene más, no puede seleccionar cuales se mostrarán ni el orden.

06 marzo 2007

RSS como sitemap.

Y algo más puede hacerse con una fuente RSS. Por ejemplo, usarla como un sitemap, es decir, un mapa del sitio. La utilidad de los sitemaps es usarlos como colección de enlaces a las páginas de su website. Da una estructura, normalmente jerarquizada de qué páginas enlazan con cuáles, facilitando la labor de rastreo del web de un motor de búsqueda. Es como un plano de su sitio web.
Todos los webs deben contar con una página de este tipo y las aplicaciones CMS o de gestores de contenidos tipo Mambo o Joomla! admiten la generación de sitemaps automatizados. También existe la posibilidad de creárselo usted mismo, una página de sólo texto, donde figuren los enlaces a sus páginas principales de contenidos y su jerarquía, cómo enlazan entre sí.
Un sitemap puede ser incluso muy complejo para un portal lleno de contenidos y además hay que tener la confianza en que un motor llegue a encontrarlo y se tome la molestia de leerlo completo y agregar todos los enlaces posibles a su base de datos, algo que no es seguro ni instantáneo.
¿Por qué no enviárselo directamente?
Puede hacerse, y hay diversos formatos de sitemaps, incluso hay aplicaciones que te los crean.
Pero uno puede hacerlo con una fuente RSS. Es crear un fichero XML como el ya descrito donde se encuentren los enlaces del sitio, sus páginas con sus URL correspondientes, hasta el nivel de profundidad que uno considere. Y posteriormente enviarlo, por ejemplo a Google.
También es preferible en vez de crear un fichero interminable, crear varios sitemaps por categorías. Por ejemplo, en mi caso me encuentro con que tengo grandes cantidades de galerías de fotos. ¿Por qué no hacer un sitemap principal y otro solo con las galerías de fotos?
Eso es lo que yo hago, además de hacer otro para los contenidos más modernos, que se renuevan, como el apartado de exposiciones o noticias. Y los envío todos.
¿Adónde?
Hay un servicio magnífico de Google para usuarios registrados (gratuito) denominado las "Herramientas para webmasters". Hay que crear un fichero (vacío) con un nombre exclusivo que te proporcionan en Google, subirlo al servidor y ellos hacen un rastreo de tu web. Respecto a los tipos de informes que te dan, es probable que hablemos en breve. Pero uno de ellos, es el de enviar un sitemap (o varios) del web que uno pretende analizar de forma continua.
Le mandas las direcciones de tus fuentes usadas como sitemaps (completos, segmentados o por categorías) y dejarle que él automáticamente analice los enlaces. Sencillo, ¿no?

RSS. Promoción en Google y Yahoo

Otra de las cosas útiles que se pueden hacer con una fuente RSS es promocionarla en los buscadores y directorios más populares. En concreto, en Google y en Yahoo.
En Yahoo en particular, está reservado a los usuarios registrados y que tienen una página personalizada llamada MiYahoo. Pueden agregar contenidos a esta página personalizada, bien con los servicios que ofrecen por defecto, como canales de noticias o bien con las propias fuentes que añada el usuario de sus sites.
También puede promocionar sus RSS en un sentido semejante a la sindicación a través del servicio de "Añadir y promocionar tus fuentes RSS" que pueden encontrarse en la dirección
http://es.promotions.yahoo.com/guia/
Repetimos, sólo para usuarios registrados (es gratis).

En Google hay otras formas, también solo para registrados (por ejemplo, a través de una cuenta gmail). Se puede añadir el contenido de la fuente a la página personalizada de Google; también se puede agregar al lector Google Reader (incluso se pueden marcar como destacados o como contenidos compartidos con otros usuarios). En ambos casos, Google asegura que se rastrea el contenido del feed y, por lo tanto, que lo incorpora a su índice.
Esto viene a completarse con la sugestión de un sitio web, que puede hacer cualquiera, bien por su URL o por una fuente RSS. En mi opinión, es preferible hacerlo con un RSS, ya que si esta fuente contiene un número de enlaces significativos a las páginas principales del site (RSS estático), las probabilidades de ser indexadas son altas. Y por propia experiencia, alcanzan las fuentes un alto Page Rank en poco tiempo. No olvidemos que estos ficheros son eminentemente texto y, por tanto, muy fáciles de leer para los motores de búsqueda.
Para ver como sugerir un sitio en Google, pruebe a hacer la búsqueda "Google addurl" y llegará a la página
http://www.google.com/addurl/
Aunque ahí solo puede sugerir la página de nivel más alto del site y no el RSS, puede proceder de otra forma que es ir desde la página prinipal de Google a través del drectorio que se encuentra en la parte superior (en Más>>>), y escogiendo las diversas categorías llegar a la página de sugerir un sitio web al Open Directory, en una categoría determinada, por ejemplo: World>>Español>>Artes:
http://dmoz.org/cgi-bin/add.cgi?where=World/Espa%C3%B1ol/Artes
Ahí sí que puede sugerir su fuente para ser agregada.
Aunque ahí no acaban las cosas. Con una fuente se pueden hacer aún mil y una diabluras más. No olvidemos que el uso de fuentes es uno de los pilares del llamado Web 2.0, la nueva internet.
En el siguiente capítulo, más.

05 marzo 2007

RSS. Sindicación, sindicar.

Siguiendo los pasos de anteriores artículos, tenemos ya nuesto o nuestros fedds RSS (en XML), convenientemente validados y los navegadores son capaces de detectarlos automáticamente, autodetection. Podemos seguir haciendo operaciones con nuestros feeds.
Una de ellas es la sindicación, sindicar un feed, que es tanto como ofrecerlo a servicios que están especializados en esta tarea. Algo semejante a cuando uno sugiere una URL para ser incluido en un directorio. Los servicios que sindican RSS no son más que eso, directorios donde se encuentran las direcciones de diferentes feeds, para poder ser agregados a lectores externos de noticias, como FeedReader o a lectores en línea como Google Reader. Para leerlos desde Google Reader, algunas páginas ofrecen unas pequeñas imágenes con la leyenda "Add to Google". Qué significa, ya lo sabe. Pulsando sobre ellos, el feed se agrega a tu página principal personalizada de Google.
Sindicar es una tarea sencilla. Sólo hay que acceder a las páginas que ofrecen estos servicios, (unas exigen registro y otras no) y sugerir la dirección de tu RSS. Y esperar a que te lo aprueben.

Puede empezarse en dos sindicadores muy famosos:

Uatsap (en español)
Syndic8 (en inglés y con registro a través de una cuenta de Yahoo!)

Si tiene problemas, navegue por las categorías del sindicador hasta dar con la que más se adecúe a la suya y sugiera desde allí. Y confíe en que no tenga problemas con la codificación de caracteres escogida y el reconocimiento de palabras tales como "diseño" o "cerámica". ¿Adivinan quién ha tenido problemas con estas palabras en concreto en sus feeds?

04 marzo 2007

Más de RSS: Detección.

Si es usuario de Internet Explorer (7), o de Firefox, o de Flock (allá usted si escogió estas opciones), que vienen a ser ambos un poco de más de lo mismo (todoscontramicrosoft), habrá observado que aparecen una serie de botones naranjas con un diseño un poco retro en sus barras de navegación. Una especie de indicador de estación de radar de cuando la guerra fría.
También habrá observado que en unos sitios el botón no es naranja sino gris, con un aspecto más bien apagado. Si está naranja (encendido) significa que el site posee feeds dispuestos a ser consultados en el mismo navegador o agregados a un lector de noticias. Incluso usted puede agregarlos a sus contenidos favoritos de sus páginas personalizadas de Google o MiYahoo, si son, por ejemplo, las novedades del periódico de sus entretelas. O puede leerlos habitualmente desde Google Reader o cualquier software conocido como lectores de noticias, o de feeds o como quieran llamarlos.
No solamente el sitio los posee sino que el navegador es capaz de detectarlos automáticamente y avisar a los navegantes (incluso con sonido de aviso y todo).
Si ve el icono de "Fuentes", que es como lo llama Explorer, apagado (gris), una de dos: o el sitio no posee "fuentes" o el navegador no es capaz de detectarlo automáticamente.
Aquí nos dedicamos a este aspecto: la autodetección de ficheros RSS. Es fácil.
Solo hay que copiar el código que a continuación les proporcionamos en la página que quiere que aparezca como suministradora del feed, una cualquiera de su web (o todas, si así lo prefiere).

{Como siempre, las etiquetas van entre < y >, no entre corchetes, como ya se ha explicado hasta el cansancio de los lectores}.

[link rel="alternate" type="application/rss+xml"
title="{aquí se incluye el título que quiera, sin las llaves que son solo de comentario}" href="http://www.misitio.com/rss.xml" /]

donde www.misitio.com ha de ser sustituido por la dirección de su sitio en internet y rss.xml por el nombre de fichero de su feed particular.

Este pedazo de código se incluye dentro de la etiqueta [head], de su página web, por ejemplo debajo del título de la misma, etiqueta [title] y nunca dentro de la etiqueta [body].

Si tiene varios RSS, puede ofrecer unos en unas páginas y otros en otras, por ejemplo, para un periódico, las novedades de nacional en todas las páginas de información nacional, las últimas noticias de deportes en las de deporte, etc. Solo hay que hacer los cambios lógicos de llamar en cada página al feed correspondiente, por ejemplo: rssnacional.xml, deportesrss.xml, etc.

No hay mucho más que decir. Cuando un navegador llega a esta página el botoncito naranja aparece iluminado ofreciendo el contenido de la fuente al visitante, que puede visitarla directamente, agregarla en los exploradores mencionados ("agregar fuentes o suscribirse"), del mismo modo que lo que hasta ahora eran los favoritos, para tener constancia actualizada de las novedades ofrecidas, o tomar nota del nombre del fichero para agregarlo a su lector de feeds, etc.

RSS fácil y útil. Validar un feed.

Si ha seguido los artículos anteriores, ya tendrá un fichero feed tipo RSS basado en XML, aunque sea básico y, en mi opinión, mejor que sea así, porque aún no le veo la gracia a incluir imágenes o scripts externos a este tipo de ficheros, no es su finalidad. Es una opinión de un ignorante, así que no le den mayor importancia de la que tiene.
Ahora, bien, ¿qué podemos hacer con él?
Pues en primer lugar verificarlo, es decir, comprobar que es válido, que un navegador lo puede encontrar fácilmente y que no posee errores. Hay múltiples lugares en internet que dan este servicio y si escriben en un buscador "validar RSS", seguro que dan a la primera con alguno de ellos. Y probablemente les den resultados diferentes (o equívocos), sobre todo referente al tipo de codificación soportado en el servidor.
Se les manda la direción del fichero donde se encuentra alojado y si comprueban que lo pueden encontrar (URL válida) y que no contiene errores, te dan un aplauso y esas especies de efusiones afectuosas tan comunes en internet.
Una vez validado, lo más probable es que le ofrezcan una imagen del tipo "XML" o "RSS", de color naranja por lo general, que puede incluir en su página favorita, (o en todas, si quiere) y vincular desde esta pequeña imagen a la dirección de su fichero alojado en su dominio. Así, cuando un visitante pulse sobre este pequeño icono, accederá directamente al contenido actual del feed y podrá navegar a través de él a las páginas que más le interesen, ya que, no lo olvide, las etiquetas [guid] de cada [item] contienen esa información, la direccción de las páginas que usted ofrece como interesantes o novedades.
También algunos de estos servicios de validación ofrecen imágenes que puede incluir en su página para que cualquier visitante compruebe que el feed es válido. No confundir con lo dicho anteriormente, que la historia va por otro lado: es simple promoción de los servicios que validan feeds, para darse a conocer.
Y una cuestión lingüistica: ¿por qué en tantas páginas dicen que feed significa "propina" en inglés? Propina es tip. De ahí esa expresión tan chic de los tips & tricks. La acepción común de "feed" y que aprendimos de los dibujos del coyote y el correcaminos, es que significa alimento o alimentar, como verbo. Recuerden las trampas con el cartelito feed free del pobre coyote. Pues ese es su sentido estricto: alimentar de contenidos a los lectores de feeds.
Una leyenda urbana más, la del significado de "feed" y como suele ocurrir habitualmente, falsa.

RSS basado en XML (III). Los items.

(...viene de la entrada anterior)

Recapitulemos: hemos establecido el lenguaje (XML), la codificación (UTF-8), la versión del feed (RSS 2.0), el sitio web (channel), su dirección o URL (link), su título (title), descripción (description) y el idioma (es).

A continuación vienen las etiquetas [item] que hacen referencia a cada una de las páginas donde se encuentran los contenidos que deseamos ofrecer, bien sean contenidos estáticos que no cambian con el tiempo, o bien las novedades que deseamos que aparezcan como contenidos nuevos en los lectores de feeds, etc. Es decir, lo que usted desee.

Volvemos a recordar que no ha de olvidarse que todas las etiquetas han de estar duplicadas (apertura y cierre), que las de cierre se preceden de una barra /, y que las etiquetas van entre < >, no entre corchetes como en el ejemplo. (Perdonen la pesadez, pero esto del copia y pega le pone a uno vicioso del hablar por hablar).

La etiqueta [item] lleva una serie de etiquetas anidadas a su vez que son, fundamentalmente, (pueden añadirse otras):

[title]: el título de la página individual, que no tiene por qué coincidir con el del channel.
[guid]: la dirección URL de la página en concreto y que pertenece al dominio establecido en el channel.
[description]: descripción del contenido que se ofrece en esa página, el producto o la novedad a la que se refiere.

Pueden añadirse otras etiquetas referentes al autor, por ejemplo, si es que hay varios editores para el sitio, etc., pero eso ya es de nota.

Pueden incluirse tantos [item] como se deseen, pero lo lógico para un RSS que se usa como alimentador de noticias, es ofrecer los contenidos nuevos del web y así facilitar que un visitante habitual llegue fácilmente a encontrarlos sin necesidad de navegar por todo el web.
Por el caso contrario, pueden incluirse tantos [item] como páginas deseemos que sean conocidas por un buscador tipo Google o Yahoo, cuando les remitimos un mapa del sitio (sitemap) en este formato de RSS.
Así que nuestro fichero RSS puede ser o bien escueto con solo las novedades, o bien largo, en caso de querer mandar un número elevado de direcciones de páginas independientes.
O ambas cosas, porque lo bueno del asunto es que en un sitio web no hay restricción respecto al número de ficheros RSS que pueden ser ofrecidos, ni a su longitud ni complejidad.

Pongamos por ejemplo que queremos ofrecer dos páginas de nuestro sitio, con lo que nuestro fichero RSS basado en XML podría quedar definitivamente de la siguiente forma:

[?xml version="1.0" encoding="utf-8"?]

[rss version="2.0"]

[channel]

[title]Las dos Españas: la negra y la negrísima. Los Botejara(2ª parte)[/title]
[link]http://www.lacabradesdeelcampanario.com/[/link]
[description]Ameno recorrido por las simpáticas costumbres étnicas de la España más racial: despeñamiento de cabras, manteos de solteros, pasadas de forasteros por el pilón, huelgas de hambre de terroristas a base de miel y chopped y cencerradas en las bodas de viudas.[/description]
[language]es[/language]


[item]

[title]Jolgorios públicos[/title]
[guid]http://www.lacabradesdeelcampanario.com/juergas.html[/guid]
[description]La tradicional tomatina se prevé en la edición de este año que será sustituida por la melonina, donde los turistas y paisanos, en vez de arrojarse tomates desde los balcones, se tirarán melones. [/description]

[/item]

[item]

[title]Grand Prix del verano[/title]
[guid]http://www.lacabradesdeelcampanario.com/concursos.html[/guid]
[description]El programa Grand Prix del verano, que durante lustros ha sido presentdo por Ramón García, Ramonchu para los amigos, será presentado en esta temporada por algún terrorista excarcelado por el gobierno, que son más simpáticos y en vez de vaquilla se toreará a su venerable madre, a ver qué tal le sienta y a ver si tiene el estómago de pedir champán y langostinos para celebrarlo (estos tragan de todo).[/description]

[/item]

[/channel]

[/rss]


Y ya está. Mutantis mutandi, cambiando lo que usted deba cambiar respecto a su site y a sus páginas, lo esencial está hecho y solo le queda guardarlo (con cualquier nombre de su elección, tal como noticias.xml, sitemap.xml, etc.), y publicarlo en su servidor por FTP, a una carpeta o al directorio raíz de su sitio. Recuerde donde lo alojó.

03 marzo 2007

RSS basado en XML (II). El channel.

(...viene de la entrada anterior)

La etiqueta [channel] establece el web al que está referido el feed que estamos construyendo.
Incluye básicamente las siguientes etiquetas anidadas dentro de ella:

[title]: el título que le queramos dar a nuestro website. Puede ponerse cualquier cosa.
[link]: es la dirección del web al que se refiere el fichero RSS. P. ej. http://www.misitio.com/
[description]: Descripción del sitio web, un breve comentario sobre sus finalidades o intenciones.
[language]: el idioma que es usado en el sitio. Para español es es (y perdónese la repetición, que no redundancia).

No ha de olvidarse que todas las etiquetas han de estar duplicadas (apertura y cierre), que las de cierre se preceden de una barra /, y que las etiquetas van entre < >, no entre corchetes como en el ejemplo.

Así pues nuestro feed por el momento va quedando de la manera siguiente:

[?xml version="1.0" encoding="utf-8"?]

[rss version="2.0"]

[channel]
[title]Las dos Españas: la negra y la negrísima. Los Botejara(2ª parte)[/title]
[link]http://www.lacabradesdeelcampanario.com/[/link]
[description]Ameno recorrido por las simpáticas costumbres étnicas de la España más racial: despeñamiento de cabras, manteos de solteros, pasadas de forasteros por el pilón, huelgas de hambre de terroristas a base de miel y chopped y cencerradas en las bodas de viudas.[/description]
[language]es[/language]
[/channel]

[/rss]

(y continuará...)

RSS basado en XML (I)

(...viene de la anterior entrada)

Una de las formas habituales de hacer un feed es usar el lenguaje XML, algo más que un lenguaje, como la madre de todos los lenguajes del diseño orientado a objetos de internet y que se utiliza hoy en día como referente para otras diferentes lenguas y dialectos como el HTML, que se ha de buscar en sus formas compatibles, de ahí el XHTML.
Dedicarse a este rollo es estar todo el día aprendiendo sintaxis y gramáticas nuevas, ya sea a base de sentencias o de etiquetas. Pero no nos engolfemos en metafísicas informáticas que la vida es breve.

Una estructura básica de un fichero RSS basado en XML que puede ser escrito en cualquier editor de texto de nuestras preferencias o incluso en un editor de página web como Dreamweaver, (si le da pereza, puede directamente copiar y pegar) puede ser de la siguiente forma:

(Importante: No se olvide de encerrar cada etiqueta, como es habitual tanto en XML como en HTML, entre los signos < y >. Aquí se sustituyen por corchetes [ y ] para que el ejemplo no sea interpretado como un fichero XML en esta ventana del navegador.)
Para la cabecera podríamos dar la siguiente información básica:
[?xml version="1.0" encoding="utf-8"?]
[rss version="2.0"]

En estas dos etiquetas se indica que el lenguaje usado para nuestro documento es XML versión 1.0, el tipo de codificación del documento (forma de reconocimiento de los caracteres del propio documento) que escogemos uno bastante universal, el famoso Unicode UTF-8 y que va camino de imponerse. Los coreanos probablemente prefieran usar otro tipo de codificación y los evangelizados por san Cirilo y san Metodio, ya se sabe, prefieren cirílico. La segunda línea establece la versión de nuestro fichero RSS, ya que hay varios formatos, pero este parece ser hoy en día el más apropiado. También debe recordar que al igual que HTML, las etiquetas han de ser dobles por lo general, esto es, de apertura y cierre, como la propia etiqueta [rss version="2.0"], que tendrá al final del documento su homóloga de cierre [/rss]. (Continuará...)

Feeds RSS

Los feeds RSS son una forma de enviar y leer contenidos actualizados desde las páginas web. Un ejemplo concreto son las secciones de los periódicos con sus últimas noticias o un sitio web de comercio electrónico con sus últimas ofertas o productos.
Aunque es conveniente que todos los sitios web, independientemente de cual sea su finalidad, cuenten con al menos un fichero RSS que ofrecer a sus visitantes para que lo agreguen.
También es conveniente por el hecho de darle un fichero que es eminentemente texto a los robots que operan para los buscadores, rastreando la web y es una buena forma de ofrecer URLs interesantes y actualizadas a estos sistemas de indexación en los directorios de búsqueda.
Pueden usarse incluso como sitemaps o mapas de un sitio web con la dirección y descripción de los enlaces más interesantes. Una buena forma de enseñar a un buscador los contenidos más relevantes de un web, o los más modernos o aquellos que aún no han entrado en el índice de su directorio, porque les ahorra mucho trabajo y dedicación de búsqueda y rastreo a través del web a los diveros motores, spiders o robots. Estos muchachitos son muy agradecidos con este género de detalles, como el que les ahorres esfuerzos que no se van a tomar, porque su dedicación a indexar un website siempre es limitada, tanto en el tiempo como en el alcance de la profundidad de sus búsquedas.
No se trata aquí de hacer una descripción exhaustiva de estos ficheros RSS o feeds, ni de sus tipos o formatos, información que se puede encontrar fácilmente en internet, sino sólo unas recomendaciones básicas para aquellos de los que gustan de hacérselo todo ellos mismos (menos las cosas del amor) y preocuparse de la gestión de sus webs de una forma artesanal que ya no se lleva y les desagrada dejarlo todo en manos de los diversos applets a los que son tan aficionados los "profesionales" del diseño web, especialistas en hacer sitios a medida; esto es, a medida que van llegándole los clientes, les van ofreciendo soluciones que poco difieren unas de otras y hacen websites como el que hace churros.
Creo que ha salido perjudicado en el símil el honorable gremio de churreros, que a veces ponen más amor, cuidado y dedicación en su labor que los habituales genios del diseño.

(Continuará...)

27 enero 2007

Efecto EOLAS para elementos Flash

Uno de los problemas con los que últimamente se han enfrentado los desarrolladores web es la aparición del efecto (defecto) EOLAS al pasar por encima de una película Flash embebida en un documento HTML.
Es ese efecto que marca un rectángulo sobre el elemento en cuestión, con el mensaje de advertencia de que se debe hacer clic para activar dicho elemento. Y todo porque Internet Explorer da advertencias de seguridad sobre los elementos ActiveX. Curiosamente, no sobre los elementos de Javascript, potencialmente tan "peligrosos" para la seguridad como los mencionados ActiveX.
Se han propuesto diversas alternativas, desde el desarrollo de elementos de JavaScript tipo FlashObject (y posteriormente SWFObject), de un uso reservado para aquellos iniciados en el manejo y gestión de códigos. Aparte de eso, tienen estos scripts también el inconveniente de que no son visualizables directamente en los editores visuales de páginas web tipo Dreamweaver, sólo hasta la previsualización de la página.
Por otro lado, el equipo de Adobe desarrolló otras formas de combatir este desagradable defecto, sobre todo a través de extensiones descargables desde el Adobe Exchange (el antiguo Macromedia Exchange) que instalados sobre Flash, permitían hacer acciones semejantes a los elementos de Javascript anteriormente mencionados (y con los mismos inconvenientes anteriores).
Una solución aceptable y que aún puede seguirse utilizando es en el caso de que toda la web esté generada en Flash y quiera publicarse como un elemento único en HTML, para lo que la extensión (gratuita) que proporciona Adobe es realmente útil y efectiva. Pero completamente inoperante cuando el elemento es un Flash embebido o incrustado en un documento HTML.
Se instala por el método habitual con el Extension Manager y genera una opción adicional en las pestañas de publicación de un documento Flash, libre del desagradable efecto EOLAS.
Pero la solución definitiva ha sido cuando los desarrolladores de Adobe han provisto la última actualización de Dreamweaver 8.
Confieso mi sorpresa al comprobar que desde ese momento la generación automática de código a la hora de incrustar un elemento Flash en un documento HTML era limpia, transparente y efectiva al cien por cien. Y la sorpresa fue mayor al comprobar que al abrir un documento anterior con la conflictiva etiqueta "object", (causa del odiado EOLAS), Dreamweaver 8 actualizado lo detecta automáticamente y lo corrige casi sin que te enteres. Sólo hay que darle permiso para que lo realice.
Una felicitación al equipo de Adobe y una recomendación a los gestores de sitios web donde aún sigue observándose el recuadrito de marras y la advertencia sobre la activación de los controles ActiveX: hay que actualizar esos sitios, hombre, que es fácil y barato.
La actualización de Dreamweaver 8 está disponible desde la ventana de bienvenida del programa, es sencilla de descargar e instalar y se hace de forma anónima y gratuita.

Hay toneladas de información al respecto en internet, pero para ir tirando del hilo, puede empezarse desde aquí:
http://www.cristalab.com/tips/19891/solucion-a-problema-de-flash-en-internet-explorer-por-eolas
Y respecto a los antecedentes puede consultarse:
http://www.error500.net/micrsoft-pierde-eolas
Un ejemplo del feo efecto lo he dejado en una web alternativa de la escuela de arte de Talavera a propósito, con fines ejemplificantes (de momento) en:
http://perso.wanadoo.es/nemotep/

Y podríamos seguir hablando acerca de las motivaciones (por supuesto oscuras y malvadas) de este quebradero de cabeza para los desarrolladores web cuyos visitantes utilizan mayoritariamente Internet Explorer.