La primera sorpresa ha sido buscando en google. Unas búsquedas rápidas no me ha dado ningún resultado en el que se suba el fichero sin necesidad de librerías adicionales. Pensé que sería igual que con Apache/PHP, el servidor sube el fichero a una carpeta temporal y una variable le indica a nuestra aplicación PHP dónde está. En Tomcat/JSP parece ser que no es así. Insisto, quizás sí, pero no he buscado en profundidad.

Todos los resultados de google que he visto hacen referencia a que hay que usar alguna librería externa, como apache-commons-fileupload. Así que me puse a ello, usando esa librería.

La segunda pega es que al ser el form de html enctype="multipart/form-data", necesario para poder subir un fichero, en la parte del servidor JSP dejan de funcionar los request.getParameter(), siempre devuelve null. Resulta que si el request es multipart/form-data, hay que tratarlo de otra manera. Este asunto me ha llamado la atención y le ha hecho perder un puntito a JSP frente a PHP (o a Tomcat frente a Apache, no sé quién es el culpable), donde parece que  no hay esos problemas.

¿Y cómo se leen entonces los parámetros de la petición?. Pues nuevamente una búsqueda rápida en google parece indicar que la única solución es usar librerías externas y en concreto, la misma apache-commons-fileupload. Con esa librería se "parsea" la petición y obtenemos una lista de FileItem. Cada uno de ellos puede ser un fichero al que se ha hecho upload…. ¡¡ o uno de los parámetros !!. Llamando a los método getFieldName() y getString() (comprobando previamente si es parámetro o fichero) de esos FileItem obtenemos los valores.

En fin, algo que me ha parecido rebuscado y demasiado complejo frente a cómo se hace en PHP/Apache. Un pequeño tutorial de esto en la chuwiki: File Upload con JSP.

En cierta ocasión vi que la tienda tenía una página web, así que en una de mis visitas se lo comenté. El dueño me dijo que no andaba muy contento con los que se la habían hecho y que si yo sabía algo de eso, que le hiciera un presupuesto para llevarle yo la página web. Bueno, no es lo mío, sólo llevo la mía por hobby, tampoco soy autónomo así que no podría darle factura y encima soy vago. Una cosa es "jugar" con mi página web cuando tengo ganas y otra es comprometerme a algo. Así que lo dejé correr. De esto debe hacer ya cerca de dos años.

Pero hace poco volví a visitar la web y vi cosas que no me gustaron nada. Enlaces internos rotos, fotos que no salen y la página muy parada, en dos años apenas había nada nuevo. Así que le envíe un correo al dueño diciéndole que podía arreglarle la página y que siempre que fueran cosas puntuales y sin mucho trabajo, no le cobraría. Me conformaría con algún descuento/regalo en los arreglos que me fuera haciendo en la bici. Vaya, un trueque. Así que quedamos para un café … y me llamaron la atención varias cosas.

Lo primero es "hacer negocios" con gente de un negocio totalmente distinto al tuyo. Si le pregunto con quién tiene contratado el dominio y el hosting o cómo accede al panel de control, pues pone la misma cara que cuando él me comenta a mí que en una bici a medida se seleccionan unos treinta tipos de piezas y que la junta de la trócola no forma parte de ellas.

Y por otro lado, yo iba con mi idea de arreglarle un poco la página, ponerle un os-commerce para que tuviera un carrito de la compra o incluso un foro en el que la gente pudiera preguntarle on-line si tiene tal o cual pieza, cuánto tardaría en conseguirla o el precio. Pues bien, no tiene tiempo para atender el foro adecuadamente y lo del os-commerce le da igual porque casi todas las tiendas de bicis tienen y el que compra on-line al final se va al más barato, que suele ser alguna gran superficie. El lo que quería es algo que muy pocas tiendas de bicis tienen y es que un cliente pueda hacerse una bicicleta a medida, eligiendo las piezas del catálogo y hacer el pedido sobre ello. Es más, tampoco quiere que esa aplicación esté abierta al público en general, sino que sólo puedan acceder ciertos usuarios a los que él dé de alta y que hayan pasado previamente por la tienda, es decir, clientes conocidos.

Así que me pareció entretenido y a ello me he puesto. Llevo ya un par de semanas a ratos libres desempolvando mi php y me he creado un proyecto de bicis a la carta en GitHub, donde he subido una primera versión, más o menos funcional, pero todavía con faltantes y algunos ideas pendientes. A la vuelta del verano le llevaré mi bici para que le haga una revisión general por debajo del barro que tiene acumulado desde el invierno.

Por cierto, entiendo que sólo le interesen esos pocos clientes conocidos que "suelen" comprarle bicis a medida. Jugando con la aplicación y un catálogo real, haciendo bicis de forma aleatoria, no me ha bajado ningún precio de los 2000 €.

Esta es una pregunta bastante habitual en la gente que empieza a hacer aplicaciones web o, incluso en la gente que ya lleva tiempo en uno de esos dos lenguajes y se plantea si merece la pena pasarse al otro. No pretendo aquí dar una relación exhaustiva de los pros y contras de cada uno de ellos, pero sí algunos de los puntos que considero importantes a la hora de decidirse.

Librerías disponibles

Tanto un lenguaje como otro tienen muchísimas librerías disponibles para hacer un montón de cosas. JSP/Java tienes bastantes más, pero también es un lenguaje multi-propósito, por lo que muchas de ellas no nos servirán para nada en una aplicación web. PHP está más pensado para web y todas sus librerías son útiles para web. Por ello, lo único que debemos tener en cuenta en este punto concreto es qué librerías vamos a necesitar para nuestras aplicaciones y si las tenemos disponibles en el lenguaje que vayamos a elegir. En su defecto, qué nos costaría desarrollar esa misma librería.

Hospedaje en el servidor

La aplicación web debe ir en un servidor. Normalmente es más fácil encontrar servidor PHP con base de datos gratuitos que servidores que ofrezcan JSP/Servlets gratuitos. Si vamos a los de pago, también es más fácil y barato encontrar servidores PHP. Por ello, si el coste es un problema, posiblemente PHP sea mejor opción.

Si nuestra aplicación web está pensada para que la gente en general la use y la instale en sus servidores (por ejemplo, un blog estilo wordpress, una wiki estilo Mediawiki, etc), también tendrá más aceptación posiblemente si la hacemos en PHP, ya que de todos esos posibles webmaster que queremos que usen nuestra aplicación, la mayoría tendrán PHP pero no JSP.

Si nuestra aplicación es para uso particular en una empresa o en casa y el servidor nos lo vamos a montar nosotros mismos, en principio no hay ningún problema con un lenguaje u otro. Es prácticamente igual de fácil instalar, por ejemplo, un servidor Apache con PHP que un servidor Tomcat para JSP/Servlets.

La aplicación y el lenguaje en sí mismos

Entre los lenguajes Java y PHP hay una diferencia que considero fundamental. El primero es tipado, es decir, hay que declarar los tipos de las variables, los parámetros de los métodos, etc, etc. En PHP no hay tipado, se pueden usar las variables sobre la marcha y pueden contener cualquier cosa en momentos distintos de la ejecución. Java es 100% orientado a objetos, mientras que PHP permite mezclar clases con funciones de programación estructurada. Esta diferencia hace que según el tipo de aplicación, sea mejor un lenguaje u otro.

Si nuestra aplicación es una aplicación puramente web, en la que principalmente hay presentación en navegador y transacciones con una base de datos, en la que van a participar un número de desarrolladores no muy grande y el tiempo de desarrollo no muy largo, PHP puede ser una buena opción.

Sin embargo, en aplicaciones muy grandes, en la que pueda haber más código/algorítmica aparte de lo estrictamente presentación en navegador y transacciones en base de datos, va a haber muchos desarrolladores y tiene un tiempo de desarrollo largo, es mejor usar JSP/Servlets.

Y explico el motivo. Una función PHP puede parecerse a esto

function la_funcion ($el_parametro) {
   $el_resultado = ….
   return $el_resultado
}

mientras que un método similar en Java puede ser como este

public TipoResultado laFuncion (TipoParametro elParametro) {
   TipoResultado resultado = …;
   return resultado;
}

Mientras estamos codificando y con el código en la cabeza, casi da igual una cosa que otra. Pero si ese código no lo he hecho yo y tengo que mantenerlo o usarlo, o lo he hecho yo pero hace unas semanas, el código PHP no ayuda en absoluto a saber qué tipo de parémetro hay que pasar o qué devuelve (ni siquiera si devuelve algo), habría que leer el código interno de la función con detalle. El código Java, sin embargo, deja claro qué tipo espera como parámetro y qué devuelve, así que quizás no tengamos que mirar el código interno del método para usarlo.

El no saber los tipos de entrada/salida puede resolverse con una disciplina estricta y comentarios adecuados, pero recuerda, estamos hablando de un grupo de desarrolladores grande. En un grupo grande, siempre hay  un porcentaje importante de ellos que será poco disciplinado/novatos y pondrán comentarios graciosos.

Hay además otras dos ventajas fundamentales en los lenguajes tipados:

1. Los IDE tienen un autocompletar mucho mejor. Cualquier IDE de java moderno, pones la variable, un punto y te saca los posibles métodos/atributos a los que puedes llamar. Un buen IDE de PHP lo intentará, pero no siempre lo conseguirá. En el ejemplo anterior, si en java escribimos elParametro., el IDE nos pondrá los posibles métodos porque sabe que elParametro es de tipo TipoParametro. En PHP, poniendo el_parametro->, el IDE no nos puede poner absolutamente nada, porque no sabe de qué tipo es eso.
2. Precisamente por eso y por la necesidad de declarar los tipos, un IDE no nos dejará, por ejemplo, llamar a un método que no existe o asignar a una variable no declarada. PHP sí nos dejará hacerlo o nos dejará, por ejemplo, poner $nuemro (me he equivocado a posta, en vez de $numero he puesto $nuemro) y declarar sin querer una nueva variable. Todo esto fallará, si tenemos suerte, cuando hagamos nuestra ejecución. Pero si no tenemos suerte, errores de este tipo no saltarán al ejecutar, el programa símplemente no dará el resultado esperado y perderemos horas de depuración. En java directamente no compilará y el IDE nos cantará el error en cuanto lo escribamos.

Así que si la aplicación es grande y con muchos desarrolladores, es posiblemente mejor usar un lenguaje tipado.

Gustos personales

Finalmente, cómo no, los gustos personales de cada uno, las prisas, ganas de aprender, etc. Alquien puede tener preferencia por uno de los lenguajes, o bien ser el que domina y no querer meterse en el otro, o bien todo lo contrario, querer meterse para aprender. Si vas a hacer una aplicación web sencilla, pero dominas java, tienes prisa en hacerla y te importa tres pepinos PHP, posiblemente la hagas en JSP, aunque alguien que domine PHP quizás tardaría menos en hacerla en PHP.

En resumen

Supongo que al menos parte de estas razones son las causas principales por el que en el ambiente de internet al público, la mayoría de las aplicaciones son PHP (wordpress, mediawiki, etc), mientras que las aplicaciones JSP/Servlets se quedan más para ambientes empresariales o intranets. Ojo, hay cosas de ambos tipos en ambos ambientes, símplemente estoy indicando lo que parece ser mayoría.

¿A alguien se le ocurren más motivos a tener en cuenta?

Esa opción no era buena del todo. Conseguí que google indexara los temas del foro, pero tenía que actualizar el sitemap periódicamente a mano. Así que decidí hacerme un pequeño script sitemap.php que hiciera de sitemap para google de forma automática.

Este script, al llamarlo, consulta en la base de datos el campo id_topic de la tabla smf_topics. Es la única información que necesita para generar el fichero XML de sitemap. El script dice que devuelve un "Content-Type : application/xml" para que cuando google lo consulte piense que es un fichero XML, luego envía los tags XML correspondientes al sitemap.

Adjunto el código php por si a alguien le interesa

<?php
header(‘Content-Type: application/xml’);
include (‘Settings.php’);

print (‘<?xml version="1.0" encoding="UTF-8"?>’);
print (‘<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">’);

$link = mysql_connect ($db_server, $db_user, $db_passwd) or die ("<center>No se puede conectar con la base de datos\n</center>\n");
$query=’select id_topic from smf_topics’;
$result=mysql_db_query ($db_name, $query, $link);

while ($row = mysql_fetch_array ($result))
{
   print (‘<url>’);
   print (‘<loc>’);
   print (‘http://foro.chuidiang.com/index.php?topic=’.$row[0]);
   print (‘</loc>’);
   print (‘</url>’);
}
mysql_free_result($result);
print (‘</urlset>’);
?>

El include "Settings.php" únicamente incluye un fichero de configuración del foro, en el que están las variables con el nombre de la base de datos $db_name, el usuario $db_user y la password $db_passwd. Ojo, no le busqueis pegas, que las tiene. Yo no tengo ni idea de PHP.