-
6 comentarios »
Tiempo sin escribir por aquí (como dice Martín , en los blogs corporativos es indicador del buen momento de la empresa), pero Angel Retamar me invita a hacerlo con su post sobre XML. Ante el temor de ser un comentario demasiado largo, me toca post nuevo.
Y es que Ángel habla de las virtudes del XML para la configuración de aplicaciones. Y obviamente tengo que estar de acuerdo. Bueno, en parte. Porque sólo argumenta sobre las ventajas de la configuración fuera del código. Es decir, un fichero properties tendría exactamente las mismas ventajas en según que casos.
Lo que nadie me puede negar es que se ha llevado esto a unos extremos increíbles. Ángel habla de la comodidad de Struts, y yo, habiendo visto ficheros struts-config de 20.000 líneas (y no, no sobran ceros), tengo que tomarmelo con una pizca de sal. Y lo digo habiendo pecado de XMLitis en el pasado.
Primero, porque el argumento habitual de no tener que recompilar las clases me parece bastante desafortunado. Hay gente que considera que los ficheros XML son ficheros de código fuente de la aplicación, y en mi opinión, sin valorar si es bueno o malo, tienen razón. ¿Por qué?. Primero porque sin ellos no funciona la aplicación, y segundo porque en el 99% de los casos hay que reiniciar la aplicación para que tome esos cambios. Que sean dos pasos en lugar de uno me da bastante igual, pues para mi lo hace todo Ant, que no se queja si son 1, 2 o 500 pasos. Cosas de la automatización.
Pero el segundo argumento viene normalmente de los porsis. Por si un día necesito… . La verdad es que lo más probable es que ese día no llegue nunca, pero aún llegando, ¿qué hay de malo en tener una convención que nos obligue a tener menos configuración?. El famoso convention over configuration. Si tengo una acción de Struts llamada “guardar”, que normalmente devuelve “error” o “ok”, que hay de malo en sin tener que configurar nada exista siempre la convención de que vaya a las páginas “guardar_ok.jsp” o “guardar/ok.jsp” (por decir algo?). Que libertad me quita eso?. Si quiero cambiar el funcionamiento o bien tengo que cambiar la página o tengo que introducir nuevas acciones, nombrarlas, etc. de modo que el mapeo de la JSP tampoco me sirve de demasiado.
¿Quiero decir que el XML es malo?. Obviamente no. Pero si me parece que normalmente nos estamos pasando tres pueblos. Si hubiera una herramienta gráfica que nos facilitase el trabajar con ellos realmente (el Webflow del Workshop de BEA no era mal camino para el tema de struts), pero lamentablemente no es así normalmente. Navegar con los XML de algunos proyectos se hace molesto y difícil, en especial porque al final hay información (por ejemplo el acceso a una BD) que puede estar en distintos XML o ficheros properties.
Tengamos un poco de cabeza. Y si algo no se preve que vaya a cambiar, no nos compliquemos la vida hasta que sea necesario. Será que soy muy vago.
Tampoco te lo tomes como nada personal, Ángel, es simplemente una opinión más.
6 comentarios para “¿Demasiado XML?”
Deja un comentario
LO ÚLTIMO DE LINKED
- We need a great designer
- Hablar por hablar, ese deporte
- Retos para el 2010 en Linking Paths
- Sobre los premios Buber, las críticas y la acción.
- Manifiesto: En defensa de los derechos fundamentales en Internet
- Consumidos por la reinvención
- ¿Quién es tu cliente?
- El factor psicológico
- Lanzamiento: Stage
- ¡Hola Competencia! Te estábamos esperando.
RSS de los últimos artículos
- fernanda en Hacer porras en internet
(5 comentarios) - JM. en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - zp en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - alberto en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Raúl Murciano en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Javier Aldana en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios)
RSS de los últimos comentarios
Linked, el blog de Linking Paths
-
Sobre LinkedLinked es el blog de Linking Paths, la empresa aventurera e innovadora formada por Aitor Garcia, Alberto Molpeceres y Roberto Salicio. En él hablamos de nuestros productos, ideas, y de compañías que nos sirven como guía y ejemplo. Si quieres conocernos un poco mejor puedes revisar lo que hemos escrito en los archivos.Español:English:
-
Proyectos, ideas, etc.
XML ni es el problema, ni es la solución. Con XML podemos externalizar gran parte de la configuración de nuestra aplicación web, para, por ejemplo, poder cambiar ciertas cosas sin tener que recompilar, lo cual nos dá una mejora de rendimiento (un gran proyecto tarda un ratillo en compilar, generar ear, etc…), pero también nos introduce un nuevo nivel de código fuente , porque la configuración, al fin y al cabo, muchas veces es parte integrante de la aplicación, y en definitiva es como el código fuente. Éste nuevo nivel de código es un potencial nuevo nivel de introducción de errores, y esos errores muchas veces son unchecked . Un error al escribir un atributo, y zas, nuestra aplicación deja de funcionar como esperabamos.
El problema general con el XML es que no sabemos cómo usarlo para aprovechar su potencia. El programador de a pie, hará un fichero de configuración, con o sin su .dtd y a correr. En estos momentos tenemos maneras más fiables y seguras de hacer el xml participe de ser código fuente de nuestra aplicación, por ejemplo, a través del Schema , pero normalmente no sabemos aprovecharnos de estas ventajas. Así, conseguimos que ficheros de configuración puedan ser de 20.000 lineas, y además, muy susceptibles a introducir errores.
Lo que tenemos que tener en mente es que externalizar la configuración es ideal, pero hacer que la externalización sea un punto potencial de problemas de nuestra aplicación ya no lo es, por lo que hay que tener un compromiso entre utilidad y facilidad.
!XML si!, a veces, y !XML no! otras.
Me alegro que retomeis el tema, lo bueno del XML es que no hay que compilarlo, tambien es lo malo.
El codigo esta separado de la configuracion, falso en segun que proyectos. No es la primera vez que veo codigo Java en ficheros XML que se compilan con Javac. Ejemplo cloverETL.
¿ Porque XML ?
Esa es la cuestion, y sigo considerando que es porque Java es tan potente que necesitamos un lenguaje de “Script” o de “Minilenguajes”.
Realmente cuando definimos un determinado XML que permite configurar ciertos aspectos de la aplicación lo que hacemos es en mayor o menor medida definir un nuevo lenguaje. Un lenguaje de dominio que nos permite definir el comportamiento de nuestra aplicación en un nivel de abstracción mayor al que nos aporta un lenguaje de proposito general como java.
¿Cuando nos estamos pasando?, pues creo que la respuesta obedece al sentido común, cuando desarrollar usando ese lenguaje de dominio resulta menos productivo que haciendolo en un lenguaje de proposito general.
Más que hablar de si “XML si o no”, yo hablaría de “lenguajes de dominio si o no”, lo que ocurre es que la mayoría de estos lenguajes de dominio se construyen en XML, y realmente creo que XML es una tecnología fantastica para construir estos lenguajes. El verdadero problema de diseño es determinar cuando estos lenguajes son realmente necesarios y por supuesto ser conscientes de todas las dificultades que implican desarrollos de este tipo, que son muchas…
Seria posible utilizar un lenguaje similar a JAav para definir los lenguajes de dominio. En caso afirmativo, que lenguaje
La verdad es que yo no quería plantear una disyuntiva del estilo XML Si/No. Tampoco una cuestión sobre los lenguajes de dominio. Más bien dar un toque al abuso que hacemos los programadores del XML normalmente. Si ha derivado la cosa por otro lado sin duda es fallo mio.
.
Sobre los lenguajes de dominio…. la verdad es creo que es el escenario ideal para el XML, en los casos en los que la interoperabilidad entre sistemas es necesaria (que no son todos). Me explico. Los servicios web son un buen ejemplo. También los sistemas de intercambio de datos (EDI y similares), porque no sabes que va a tener la persona del otro lado.
Pero ahi, y volviendo al post inicial, es dónde entran en juego herramientas que nos faciliten el trabajo con ellos, porque lamentablemente siempre son más complicados que el típico ejemplo de agenda de contactos. Esto pueden ser editores gráficos para crearlos7modificarlos, o herramientas de programación, como por ejemplo los compiladores de WSDL de servicios web que nos generan código para tratarlos “transparentemente”.
Sobre si hacerlo en un lenguaje más parecido a Java es viable… si, si sólo lo vas a tratar en ese lenguaje. El más indicado sería el que más te guste y mejor conozcas
Ahora estamos poniendo las bases para que los analistas funcionales generen definiciones de procesos y de navagacion de manera formal, que no verbal como hasta ahora, estamos haciendo un piloto con BPEL y JSF, al final a lo que vamos es al principio de la informatica al organigrama, tanto camino andado para volver a los origenes eso si en XML (ejecutable como dicen algunos comerciales :-) ).