Automatizando la validación del “markup” (II)
Publicado por josevnz 26 Noviembre 2005 en General, Java, XML, How To's. Etiquetas: No Tags. english • español
Este articulo es en respuesta al articulo previo (con el mismo titulo) en el cual daba la impresión de que hacer validación en Java era complicado (pensaba hacer un comentario, pero por lo largo se convirtió en articulo). No sólo no creo que sea cierto, sino que además la técnica descrita en el articulo tiene una falla seria: Depende si el servició de validación de el W3 funciona o no (lo cual entre otras cosas incluye que no tengan problemas de conectividad).
El hecho de llamar al servicio de validación del W3 es ingenioso y hace que la cantidad de código a escribir sea reducida, pero por otro lado ¿está usted dispuesto a agregar esta dependencia en su aplicación comercial?. No, de hecho es una riesgosa idea.
¿Así, que como lo hacemos?. Bueno, para empezar utilizar JTidy no es tan complicado como parece. De hecho en un articulo que escribí para KodeGeek, muestro como hacer web scrapping primero “acomodando” el HTML, convirtiendolo a XHTML para luego utilizar una hoja de estilos en XSLT para crear un archivo de texto. Algo similar se puede hacer aquí para los “unit testing”.
¿Y si no quiere utilizar Jtidy?. Siempre puede utilizar un BNF parser, como JavaCC y la gramatica especial para HTML.
Y si aún desea utilizar el servicio de validación de W3, siempre puede hacer llamadas utilizando la clase de Java java.net.URL, como este programa que escribí para hacer “ping” al sitio de Bitacoras.. Es mucho más fácil de lo que parece (sino, siempre puede utilizar HttpClient de Apache).
¿Alguien se anima a continuar la discusión? :)
Es importante tener en cuenta que la discusion nunca ha sido sobre las cosas que se pueden hacer en Ruby pero no se pueden hacer en Java.
Es simplemente sobre lo simple, trivial y natural que resultan hacer *ciertas*[1] cosas en Ruby, en comparacion con lo complejidad que suele ser requerida por Java.
El articulo original muestra como un simple download y una linea en el archivo del test son todo lo que hace falta. De hecho, si solo te interesa validar la correctitud del xml, Rails ya trae incluida esa asercion.
Vuelvo y repito… no es sobre lo posible o no… todo es posible… la clave esta en que tan facil o dificil resulta.
[1] Si bien concedo el punto de dejar la variable “ciertas” indefinida, mi experiencia hasta los momentos tiende a darle un valor bastante amplio.
Sebastian:
1. La aserción la trae Rails, no Ruby. Esa diferencia sútil pero importante dice mucho. En el caso de Java es sólo cuestión de codificar esto (si es que alguien no lo hizo ya) una sola vez y llamar a la clase desde todos nuestros programas escritos en Java.
2. Es muy fácil porque se llama a un servicio externo. Depender de cosas que no controlamos en una aplicación crítica no es admisible.
No digo que no sea un pajazo hacerlo así en Rails, lo que digo es que no hay que dejarse llevar por las primeras impresiones (de hecho les di al menos 4 alternativas en Java).
Perl, Python y otros cuentan con alternativas similares :)
José Vicente:
El punto que intenté reflejar en mi post era sobre lo sencillo que es armar los “functional testing” sobre rails, en particular para resolver el issue de la validación del markup de los documentos generados.
Efectivamente coincido contigo en que en cualquier lenguaje puedes resolver la validación del markup (usando servicios Web o implementaciones particulares).
Pero hablando del caso de Java por ejemplo, ¿qué tan fácil integras esta validación en tu proceso de build? Y para concretar digamos que estamos usando ANT o Maven.
A lo mejor las cosas han cambiado recientemente, pero hace un año atrás usar jtidyservlet (cierto estaba en pañales) dentro de los tests de un proceso de build hecho con Maven era simplemente insufrible, la cantidad de código que había que echar en los scripts (jelly) Maven para cambiar descriptores, etc…, simplemente no justificaba la inversión de tiempo, mientras había más cosas que hacer en el proyecto (los test no son el producto final, son prácticas para mejorar el producto)
asdasd