Actualmente hay muchos sistemas operativos móviles (iOS, Android, Windows Phone, webOS, BADA, Symbian, BlackBerry, …) Todos tienen virtudes y desventajas para los usuarios, por ejemplo en Android hay muchas aplicaciones gratuitas, en iOS las hay de pago pero con mucha calidad, …

Pero desde el punto de vista del programador, ¿qué nos compensa más? La respuesta más rápida suele ser iOS y Android, en iOS podremos ganar dinero, ya que la gente está acostumbrada a pagar por usar una aplicación, y en Android una gratis con publicidad y otra de pago sin publicidad, por si alguien la quiere sin pagar. En este sentido están apareciendo muchas aplicaciones creadas en HTML5 + CSS3 y montadas como nativas con PhoneGap[3], según los datos de PhoneGap, se han publicado más de 50.000 aplicaciones ya hechas con esta tecnología.

Esta forma de desarrollar aplicaciones no está mal, pero se queda en la superficie de lo que es una aplicación móvil, en realidad no es más que una página web a la que la encapsulamos dentro de una aplicación, y gracias a la API interna JavaScript se pueden hacer muchas cosas e interactuar con el teléfono.

El problema viene cuando quieres hacer aplicaciones más grandes y serias. En ese caso hay que ir a desarrollar directamente con las herramientas que nos facilitan los creadores de los sistemas operativos móviles.

La verdad es que no he visto nunca el XCode, en mi Mac mini con un G4 no van los que se pueden utilizar para programar para iOS, pero por lo que he leído o me han comentado amigos programadores, es un lío, para empezar el lenguaje Object-C tiene una curva de aprendizaje muy lenta, y luego la plataforma está muy cerrada, te puedes matar programando la mejor aplicación del mundo, que luego si Apple dice que no quiere publicarla, te tienes que aguantar o ir a Cyndia.

En Android he hecho pequeñas cosas, lo que a mi me frena es el Java, como programador .NET que soy, pero si la verdad es que le viera que se puede sacar dinero, me gastaría los 400$ de la licencia del MonoTouch (que también vale para iOS), pero el problema, como programador a la plataforma Android es que hay de todo y Gratis, para hacer algo que se pueda vender, tiene que ser muy buena y tener suerte que a la gente le guste mucho y se decidan a pagar. Otra cosa que me frenó en el desarrollo de aplicaciones para Android es que los fabricantes se han puesto en una guerra de ver quien tiene el móvil más potente y cada 2 ó 3 meses aparecen móviles o tablets más potentes, y sin actualizar el sistema de los anteriores modelos, creando una gran Fragmentación del sistema, y en muchas veces las apliciones hay que hacerlas 3 ó 4 veces, para los distintos tipos de sistemas que tiene la gente instalado (4, 3.1, 3.0, 2.3.5, 2.3, 2.2, 2.1, ……). En cuanto al argumento de la publicidad, hablando con mi amigo Jero, que hizo un par de aplicaciones y ahora trabaja en Alemania programando para una gran empresa de Software para Android, me dijo que por clic dan una miseria, además otros desarrolladores a los que han entrevistado en Droidcast[4] dicen lo mismo, que de ésto no se vive, más o menos es un hobby o que te contrate una empresa que quiere la aplicación para dar más servicios a otra cosa con la que va a ganar el dinero (un ejemplo de esto es Spotify, que solo se puede usar si tienes una versión de pago). En cuanto al diseño de las aplicaciones, Eclipse no es el mejor editor de los interfaces, y toca echar mucho tiempo delante de la pantalla para que quede algo muy bien.

Por último tenemos el Windows Phone 7.1 (7.5 como nombre comercial). Desde mi punto de vista este va a ser el sistema tapado, al haber en el Marketplace unas 35.000 aplicaciones, es el momento de ponerse a programar, hay pocas aplicaciones, y teniendo en cuenta que la versión 7.0 era muy recortada en funcionalidades, con esta versión se pueden hacer cosas muy buenas, y con suerte hacer algo de dinero, al menos para pagar los 75€ que cuesta poder publicar en el Marketplace. Otra cosa que considero a tener en cuenta es la entrada de Nokia en el ecosistema de Windows Phone, aunque parezca que no esto se va notando ya, los fabricantes de móviles están poniéndose las pilas por si triunfa, como por ejemplo ZTE, Fujitsu o Lenovo, que estaban centradas en Android. Una cosa que ha hecho muy bien microsoft es bloquear el hardware, algunos pensarán que eso es malo, pero lo bueno es que todos los móviles de la primera generación de Windows Phone se han actualizado sin problemas a la versión 7.1 (Mango), por lo que la Fragmentación es del 0%, y lo más importante, como el hardware es cerrado, los fabricantes no han hecho nada, todo lo ha hecho Microsoft, de aquí debería aprender Google con su Android. Otra cosa que me ha gustado mucho de Windows Phone 7.1 es que las herramientas de desarrollo son muy buenas, y gratuitas, lo que nos permite hacer aplicaciones con mucha calidad sin tener que hechar mucho tiempo delante de la pantalla. Otra cosa muy interesante es que te permiten hacer en una misma aplicación una versión Lite y una Pro, de manera que con una variable interna puedes cambiar las cosas que consideres que deben estar en una o en otra. También permiten otra cosa que me ha parecido muy interesante, que es la publicación privada de aplicaciones, de manera que se suben al marketplace, pero solo es visible metiendo una dirección que te proporciona Microsoft. Además Microsoft como está viendo que lo que la gente quiere son aplicaciones, está echando el resto en las comunidades de desarrollo, con charlas en muchas ciudades españolas, así como una gran documentación on-line, tanto en español como en inglés, que al fin y al cabo es lo más importante para los programadores, poder tener información para poder programar.

Después de todo esto, verás que me he “evangelizado” para empezar a desarrollar aplicaciones para Windows Phone 7.1. A ver si empiezo a sacar cosas y las voy publicando por aquí.

Enlaces:
[1] http://www.xataka.com/analisis/motorola-atrix-analisis-iv-el-motorola-lapdock-y-el-hd-multimedia-dock
[2] http://www.xataka.com/analisis/motorola-atrix-analisis-i-el-smartphone-que-queria-ser-portatil
[3] http://www.phonegap.com
[4] http://www.droidcast.es

Lo primero que hacemos, una vez que MOTODEV nos ha pedido que nos actualicemos, por si hubiera algo nuevo. Ya cuando reiniciemos el MOTODEV nos pondremos manos a la obra. Para ello lo que tenemos que hacer es crear un nuevo proyecto de Android, para ello seleccionaremos la opción del menú principal File -> New -> Project y se nos abrirá la siguiente ventana.

Pincharemos sobre Android Project, una vez que hemos pulsado sobre Android en el árbol de Asistentes (Wizards).

Seleccionar el tipo de proyecto Android

Tras esto nos aparecerá la siguiente ventana de configuración del proyecto Android.

Configuración del proyecto Android

En la imagen se puede ver que se han marcado con números los campos más importantes de configuración del proyecto.

1. Nombre del proyecto.
2. Plataforma Android para la que vamos a desarrollar nuestro programa, en el ejemplo he marcado Android 1.5 (CupCake).
3. Nombre de la aplicación, la que nos aparecerá en el menú de aplicaciones del móvil Android.
4. Nombre del paquete. En realidad se podría poner el nombre del proyecto, pero desde google nos hacen la recomendación de poner primero un identificador del programador o empresa desarrolladora de la aplicación, en el ejemplo plf, de Petra Link Factory, punto y el nombre del proyecto.
5. Nombre de la clase de tipo Activity de nuestra aplicación. No es obligatoria, pero sí recomendable.
6. Botón de Finalizar para terminar de configurar el proyecto Android.

Tras esto podremos ver que se autogeneran la siguiente estructura del proyecto, que podemos ver en la image.

Estructura del programa HelloAndroid

Podemos ver que el proyecto cuelgan varios items, que a su vez tienen otros items.

• En la carpeta src nos encontramos las clases que vayamos a programar para nuestro programa, por esto encontramos el nombre del paquete, y debajo fichero holoAndroid.java, que contiene la clase Activity de nuestra aplicación.
• En la carpeta gen nos encontramos los fichero que se autogeneran al manipular otro ficheros.
• Android 1.5. En esta carpeta nos encontramos todos los archivos necesarios de Android 1.5 (el que configuramos en nuestra aplicación).
• assets: la verdad es que no tengo idea de lo que va en esta carpeta, que se puede ver que está vacía, yo soy un novato en esto del Android, con lo que os pido perdón.
• res: en esta carpeta estarán los ficheros que nos servirán para la parte gráfica de nuestra aplicación.
  • drawable: aquí­ guardaremos los archivos de imágenes. El archivo icon.png será el archivo de nuestra aplicación, que podremos cambiar, debe ser un PNG de 48×48 pixeles. Para que funcione bien, el PNG no debe tener capas y puede ser transparente.
  • layout: en esta carpeta estarán los ficheros xml que definirán las ventanas de nuestra aplicación. Para su desarrollo tenemos un editor, con lo que no será necesario que abramos el fichero xml y editarlo a mano.
  • values: en esta carpeta podremos poner ficheros de xml de constantes, al igual que en el caso anterior tenemos un editor de este tipo de ficheros.
• AndroidManifiest.xml: Este es el fichero donde se indican datos del programa, como la versión, nombre de la empresa desarrolladora, o desarrollador del programa, …
• default.properties: este fichero no hay que tocarlo, puesto que de su modificación se encarga el plugin ADT de Eclipse

Por defecto ya tenemos el HolaAndorid en el proyecto. Si abrimos el fichero strings.xml dentro de la carpeta values veremos la cadena con el nombre “hello” y el valor “Hello World, helloAndroid!“.

Cómo se está mostrando este texto en la pantalla. Pues para ello vamos al fichero main.xml que está dentro de la carpeta layout. Ahí vemos el editor de la ventana.

Editor de la ventana de Android

Podemos ver que en el ejemplo de helloAndroid hay una TextView. En la barra de la izquierda podemos encontrar dos tipos de Items, Layout que son los tipos de panel para la disposición de los demás componentes de la ventana, y Views que son los componentes con los que podemos ver en la pantalla, botones, campos de texto, …

Para el primer ejemplo ya hemos visto muchas cosas, ya a medida que vayamos viendo otros ejemplos iremos viendo más cosas, así como el uso de los demás ficheros. Ya solo nos queda ver cómo queda nuestra aplicación en el emulador. Para ello pulsamos el botón Run (un círculo verde con un triángulo blanco dentro) que hay en la barra de herramientas. A continuación nos aparecerá el emulador de Android, con el texto A N D R O I D. Tened paciencia puesto que tarda un poco en cambiar al logotipo de Android, y luego un poco más hasta que nos aparece el sistema cargado, lo que tengáis un teléfono Android os daréis cuenta que tarda más o menos lo que tarda vuestro móvil en arrancar.

HelloAndroid en el Emulador de Android

En la última imagen del emulador la he puesto para mostrar cómo quedaría un icon.png diferente al que viene por defecto, por esto que los dos iconos están remarcados con un círculo rojo.

Si no tienes paciencia y quieres ver otros sitos webs con programación en castellano de Android te recomiendo que vayas a los blogs y foros específicos de este tema como and.roid.es y android-spa, donde hay gente muy maja detrás de estos dos sitios webs y que saben mucho sobre el tema, además que se dedican a desarrollar aplicaciones en Android.

Enlaces:

[1] Página oficial de instrucciones del instalador del plugin ADT para eclipse: http://developer.android.com/sdk/eclipse-adt.html

[2] MOTODEV: http://developer.motorola.com/docstools/motodevstudio/

Hay que decir que en la Web de Moodle hay un directorio con muchos temas que pueden ser modificados libremente [1]. En esta serie de artí­culos vamos a ver como hacer un tema utilizando como base otro ya existente. Para ello lo que debemos hacer duplicar el tema `standard` y ponerle el nombre que deseemos, en mi caso será `plf`. Utilizamos el tema standard puesto que nos aseguraremos que va a funcionar correctamente, puesto que tendrá todos los ficheros necesarios del tema.

Dentro de la carpeta nos encontramos una serie de archivos:

• config.php: Fichero de configuración del tema.
• docstyles.php: Fichero encargado de cargar los CSS, este fichero también puede contener sintaxis CSS.
• favicon.ico: Icono que queremos que se vea en nuestro navegador. El que viene por defecto es el logotipo de Moodle. Si quieres crear un favicon a partir de una imagen te recomiendo que lo hagas desde Dynamic Drive [2].
• footer.html: Fichero que contiene la platilla html del pie del sitio web.
• gradient.jpg: Este fichero contiene el degradado del tema standar. En mi caso no lo voy a utilizar y lo borraré.
• header.html: Fichero que contiene la plantilla html de la cabecera del sitio web.
• meta.php: Fichero en el que se pueden insertar tags metas para al cabecera.
• README.html: Fichero de información del tema.
• rtl.css: Fichero para estilo cuando la dirección del texto es de derecha a izquierda.
• screenshot.jpg: Fichero con un pantallazo del tema (Este fichero se cambiará al final de terminar el tema).
• styles.php: Fichero de configuración de los estilos.
• styles_color.css: Fichero para poner los colores de los estilos.
• styles_fonts.css: Ficheros para poner las fuentes de los estilos.
• styles_ie6.css: Ficheros para las cosas especí­ficas de Internet Explorer 6.0.
• styles_ie7.css: Ficheros para las cosas especí­ficas de Internet Explorer 7.0.
• styles_layout.css: Fichero de definición de los estilos.
• styles_moz.css: Fichero para las cosas especí­ficas de Mozilla Fire Fox.

Manos a la obra

Lo perimero que tenemos que hacer es cambiar el fichero README.html, para poner el nombre de nuestro tema y la información que nos apetezca.

Lo segundo que haremos será modificar el favicon.ico (si es que querremos).

Bueno, ahora entramos en el Moodle y cambiamos el tema, para ello una vez que entramos como administrador de Moodle y nos dirigimos a Apariencia -> Temas -> Selector de Temas y seleccionamos nuestro tema. Como solo hemos cambiado el fichero README.html (para ver su contenido en el selector de temas podremos ver el enlace información) y favicon.ico, con lo que la apariencia será la misma que la del tema standard. Lo seleccionamos y empezaremos a cambiar las cosas.

En el siguiente artí­culo veremos cómo ir modificando los demás ficheros.

Enlaces.

[1] Temas de Moodle: http://moodle.org/mod/data/view.php?id=6552

[2] Dynamic Drive favicon generator: http://tools.dynamicdrive.com/favicon/

Lo primero que tenmos que hacer es descargarnos el fichero dese la web de la librería [1]. El sitio está en Francés, por lo que voy a poner el enlace directo de la descarga de la versión actual a día de hoy es la 3.13 [2].

Una vez que ya está descargado descomprimimos el contenido en un directorio.

Nos encontramos con 4 directorios y 6 archivos, de aquí solo nos quedaremos con 3 directorios (_fpdf, _mypdf y languages) y con 3 ficheros (html2pdf.class.php, parsingHTML.class.php y styleHTML.class.php). Yo te recomiendo que guardes todo esto en un directorio dentro del directorio donde guardes los includes en tus proyectos, en mi caso es includes.

En este artículo voy a enseñar 3 ejemplos que son bastante censillos.

Ejemplo 1:

Este ejemplo es muy sencillo, no es más que poner un texto y generar un PDF con dicho texto.

Lo primero que vamos a ver en este ejemplo son los tags especiales. Hay 3:

• page: con este tag delimitamos el contenido de una página. En este indicamos el tipo de documento y los margenes left y top, el bottom y right no se pueden poner.

  <page backtop="10mm" backbottom="10mm" backleft="10mm"> ... </page>

  El contenido que hay dentro de este tag es lo que se muestra en la página del PDF.
  Cuando insertes el código HTML recuerda que las propiedades las debes poner en el parametro style, como por ejemplo en una tabla, deberías poner <table style=”width: 100%px; color: black;”>

• page_footer: Pie de página. Esta etiquieta debe estar dentro de la etiqueta page y su contenido puede ser un html.
• page_header: cabecera. Esta etiquieta debe estar dentro de la etiqueta page y su contenido puede ser un html.

Aquí puedes ver el fichero pdf generado en este primer ejemplo.

Ejemplo 2:

En este caso el contenido de lo que vamos a mostrar lo vamos a recoger de una plantilla y sustituimos datos de dicha plantilla desde el código.

Aquí puedes ver el fichero pdf generado en este primer ejemplo.

Ejemplo 3:

En este último ejemplo lo que vamos a ver los distintos códigos de barras que puede sacar la librería html2pdf.

Aquí puedes ver el fichero pdf generado en este primer ejemplo.

Documentos del artículo.

Desde aquí te puedes descargar todos los ficheros del artículo.

Enlaces:

[1] http://html2pdf.spipu.net/

[2] http://prgm.spipu.net/?id=29&download

En principio hay que decir que hay muchos componentes y librerías para hacer los PDFs en PHP, pero aquí solo me voy a centrar en hablar de las soluciones que he encontrado libres y daré mi opinión sobre el tema.

Antes de nada piensa qué es lo que tienes que sacar en PDF, puesto que dependiendo de la forma que generas el PDF será más sencillo o más difícil de mantener la aplicación.

RTF (Ritch Text Format)

Lo ideal es utilizar ficheros RTF como plantilla, se pueden hacer desde un fichero de Microsoft Word o desde el Writer del OpenOffice.

La ventaja de esta técnica de generar PDFs es que las plantillas RTFs son muy fáciles de mantener, sólo hay que poner unos tags dentro del fichero, y como los RTFs son ficheros de texto, se pueden abrir desde PHP, guardarlos en una variable y cambiar lo que se quiera, para luego guardarlo en otro fichero RTF.

El problema de esta técnica es que en PHP no hay componentes o clases que te permitan hacerlo desde el Apache, sin instalar software adicional, con lo que en los hosting compartidos esta opción es inviable, o al menos yo no lo he encontrado (he buscado componentes de pago, pero los que encontré eran realmente caros y ya no me compensaban). La opción económica para hacer este caso es tener un hosting privado e instalar la OpenOffice y creo que unos paquetes especiales de la OpenOffice, para así poder utilizar el Writer en modo consola y transformar el fichero RTF a PDF.

FPDF [1]

La FPDF (FreePDF) es una implementación gratuita de la PDFLib (que es de pago), aunque la PDFLib hoy en día trae añadidos de seguridad del fichero PDF generado, como imposibilidad de copiar, de imprimir, cifrado, …

Esta es la librería PHP principal que vamos a ver, puesto que las demás que vamos a ver son librerías que heredan de ella, en algunos casos modifican un poco el código para optimizar o facilitar el uso de la extensión de la librería.

De todas las que he encontrado es la que mejor está documentada, aunque en todas las librerías se pueden encontrar un directorio con ejemplos.

En esta librería para generar un PDF tenemos que programar el contenido del PDF.

Una de las ventajas de esta librería es que como es de las más usadas, tiene una pagína donde podemos ver ejemplos de scripts para hacer funcionalidades que no están dentro de la librería, la sección Scripts de la web [2].

Por último, decir que aquellos que seais unos multiprogramadores como yo, hay una implementación de la libreria para ASP 3.0 [3]. Yo no la he probado, si alguien lo prueba por favor que me comente algo.

HTML2PDF [4]

Esta librería es una extensión de la FPDF, que nos permite poner como contenido del PDF un documento XHTML. Por desgracia la poca documentación que hay está en un foro en Francés y todavía esta en desarrollo, puesto que hay muchos estilos de CSS que no los reconoce.

Es una buena alternativa a los RTFs cuando se quiere hacer una plantilla que va a ser modificada cada cierto tiempo, puesto que modificar un XHTML es muy sencillos con programas como el Adobe DreamWeaver o Microsoft Expresions, o incluso la Microsoft Office o la OpenOffice, aunque para estas dos últimas opciones necesitaremos retocar el código para adaptarlo al código que interpreta la clase.

Tiene pocos ejemplos, pero la verdad es que son suficientes para enseñar las cosas que hace esta librería PHP.

TCPDF [5]

Sin dudas una de las mejores extensiones a la librería FPDF. En su web encontramos una amplia documentación, además es la librería que tiene más ejemplos, un total de 36 ejemplos en el ZIP que nos descargamos desde la web. Además de las cosas típicas que nos permiten todas las librería que he encontrado (insertar código html, cabeceras, pies, …) nos permite crear Códigos de barras para insertarlos en los documentos PDFs que vamos a mostrar. En algunas ocaciones esto es muy útil.

Una cosa que he visto que no he encontrado en otras librerías de PHP es que tiene soporte para incrustar JavaScript para la comprobación de datos de los formularios para los PDFs generados.

Por último decir que esta librería soporta texto Unicode UTF8, con lo que nos permite realizar documentos PDFs en caracteres no indoeuropeos, como el árabe, ruso o chino.

mPDF [6]

Esta librería al igual que la anterior también está muy  bien documentada y en inglés. Esta librería es una extensión de la FPDF que soporta texto Unicode UFT-8, y está especializada en este aspecto. A primera vista, no la he probado todavía, es muy similar a la librería anterior (TCPDF). Una de las cosas que más me han sorprendido es que esta librería es la que más fuentes trae por defecto, de echo el fichero zip de todas las demás librerías apenas llega a los 1Mb, esta librería tienen un zip de 11Mb. Esta cantidad de Mb se deben a las fuentes y a los ejemplos, que  también tiene un motón de ejemplos.

Conclusión

Hemos visto en este artículo una librería y cuatro extensiones de ésta. Cada una tiene sus ventajas y sus inconvenientes. En la medida de lo posible voy a intentar investigar un poco más de cada librería e intentaré hacer un artículo más en profundidad y código de las distintas librerias que hemos visto anteriormente. En la actualidad yo he utilizado la HTML2PDF, puesto que es la más sencilla desde mi punto de vista para trabajar con HTML, para el poco tiempo que he tenido para estudiar el funcionamiento de las librerías, si en vez de 2 días hubiese tienido 2 ó 3 semanas hubiera podido ver todas las posibilidades con más detenimiento, y a lo mejor hubirera podido seleccionar otra librería, pero nunca se sabe, la verdad es que lo fácil que es trabajar con la HTML2PDF es asombroso, pero tiene muy pocas fuentes de texto, o al menos las que vienen por defecto, repito que he tenido muy poco tiempo para investigar más.

Enlaces:

[1] FPDF: http://www.fpdf.org

[2] Página de Scripts de FPDF: http://www.fpdf.org/es/script/index.php

[3] ASP FPDF: http://www.aspxnet.it/public/default.asp

[4] HTML2PDF: http://html2pdf.spipu.net/

[5] TCPDF: http://www.tcpdf.org/

[6] mPDF: http://mpdf.bpm1.com/

Bueno vamos a lio con las URL Amigables.

Lo primero he de decir que dependiendo de si trabajamos en IIS o en Apache, en los ejemplos iré mostrandolo.

En primer lugar decir que las pruebas las he desarrollado sobre Windows Vista Home Premium con el Servidor Web WampServer 2.0, aunque luego lo he probado en un Windows 2003 Server con IIS 6 y en Debian Linux con Apache 2.0 (en mi hosting de Powweb).

Si estamos en Apache lo primero que tenemos que hacer es crear un fichero .htaccess para poder redirigir las urls amigables a las páginas que corresponden, para ello recordamos que el artículo I se dice que vamos a utilizar esta pequeña chapuza.

En el fichero .htaccess escribiremos el siguiente texto.

ErrorDocument 404 /urlAmigables/controllers/controller.php

Esta línea que se introduce en el .htaccess significa que si genera el error 404 en el servidor (Página no encontrada) que se vaya a la url /urlAmigables/controllers/controller.php, Es en este fichero donde se va a hacer el procesado de la URL para luego ejecutar dentro las acciones pertinentes.

El llamar a esta página controller.php tiene que ver puesto que esta idea se me ocurrió aprendiendo a utilizar las Frameworks de PHP, que para mi gusto están bien para hacer desarrollos pequeños, en desarrollos más grandes es mejor utilizar, desde mi punto de vista, herramientas propias.

En el fichero controller.php debemos introducir:

En el IIS en vez de poner el fichero .htaccess, hay que cambiar la url del error 404, si tienes acceso al IIS de tu servidor, deberás acceder a él y luego en el sitio web cambiar las direcciones de error del 404 (por defecto vienen 3) y ponerlas a este fichero. Sino tienes acceso al IIS, seguro que tu servicio de hosting tiene en algún lugar algún sitio donde poder cambiar dicho fichero.

Pues ya está solo hace falta hacer el fichero de error para cuando se introducen direcciones que no son válidas (error404.php) y los ficheros de nuestras herramientas, en el ejemplo es modulo.php, que responde a las url amigables modulo1 y modulo2.

Puedes ver un ejemplo de esta forma de trabajar en http://urlamigables.petralinkfactory.com

Y te puedes descargar el ejemplo desde: http://urlamigables.petralinkfactory.com/urlamigables.zip

En este post voy a explicar cómo hacer lo de las URLs amigables sin utilizar el módulo de Apache Rewrite y sin necesidad de ningún componente (para IIS).

Para empezar lo primero que tenemos que ver qué son las URLs amigables. Estas URLs son las direcciones pero sin parámetros. Por ejemplo este post tiene una dirección que es http://www.petralinkfactory.com/2008/04/27/url-amigables-i. Una URL "no amigable" sería http://www.petralinkfactory.com/?post=1234 (no creo que esta dirección funcione puesto que la he puesto de ejemplo).

El truco que voy a explicar es para programar nuestras propias páginas webs, para WordPress el propio sistema nos permite seleccionar las URLs amigables en las configuraciones de los post.

Ya que no tenemos el módulo Rewrite disponible, bien por que estamos en un hosting compartido (que ya es raro que ocurra) o bien puesto que nuestro hosting es Windows sobre IIS, el truco es usar una pequeña zapuza, el error 404.

Entonces el fichero de error 404 va a ser el encargado de recoger la url y hacer las acciones pertinentes para ejecutar la página que corresponda.

Esta técnica de usar el error 404 no es recomendable para gente que ya tenga programado un sitio web entero, puesto que tendréis que cambiar todas las páginas webs que querráis que tengan URL limpias, para adaptarlas a la forma de trabajar de las URL amigables.

Para la programación de las páginas públicas yo lo que hago es analizar la url de manera que a cada módulo de la web (agenda, noticias, secciones de texto, ...) le asigno un "controlador", que no es más que el nombre del módulo, para luego seguir con los "parámetros" que van a ser necesario para dicho módulo.

En el siguiente capítulo empezaré a poner ejemplos de código.