Integración de XML y los JavaBeans

La palabra que más suena actualmente es XML, las siglas para Extensible Markup Language. Pero es más que zumbido. Esta tecnología de desarrollo rápido está bien adaptada para el uso con JavaBeans -- y complementa agradablemente la filosofía Java de escribe-una-vez, ejecuta-en-cualquier-parte que ha dado al mundo una movilidad sin precedentes en la red. Este tutorial describe sólo una posible aplicación de XML: haciendo los JavaBeans móviles e interoperables representándolos como documentos XML.

El HTML (Hypertext Markup Language) actualmente es el formato de documento para la World Wide Web. Últimamente, aunque, hay mucho ruido sobre XML (Extensible Markup Language), que permite, entre otras cosas, la capacidad de definir nuevas etiquetas de marcas (los bits entre los <angulos>), o incluso nuevos lenguajes de marcas. Algunos expertos incluso demandan que XML puede suplantar a HTML como el formato de información dominante en la Web.

Para algunos, XML se parece a una de esas ideas que, aunque excita al principio, no es enteramente utilizable en la práctica. ¿Cómo utilizaría XML un desarrollador en un sistema de la vida real? ¿Cómo de buena es la capacidad de definir etiquetas personalizadas si ningún navegador las entiende? En esta página veremos una posible aplicación de XML -- usarlo como formato de serialización para JavaBeans.

Primero, leeremos una rápida introducción sobre qué es XML y porqué está tanta gente así de excitada con él. Después, oiremos hablar del modelo de objeto del documento del Consorcio de la World Wide Web (W3C's), el estándar propuesto para representar documentos como estructuras de datos. Como ejemplo de procesamiento de un documento como una estructura de datos, describiremos un lenguaje de marcas personalizado muy pequeño, y luego implementaremos una clase que lea un fichero XML y lo transforme en un JavaBean.

Por favor, observa que el propósito principal de esta página es proporcionar un ejemplo de utilización de XML. Como no es una introducción a XML para principiantes, este página debe ser comprensible con sólo un poco de lectura preparatoria.

. ¿Qué hay de malo en el HTML?

Hay mucho material introductorio en la Web sobre XML, así que vamos a pasar rápidamente sobre los fundamentos del XML. Comencemos discutiendo en primer lugar porqué XML es necesario.

Es fácil hacer el argumento de que el HTML permitió la explosión de la Web. Entre otras muchas cosas que han hecho del HTML el formato dominante para los documentos Web están las siguientes:

  • HTML es muy fácil de aprender y de utilizar. Prácticamente cualquier persona con pulso puede aprender a escribir HTML. Leer HTML en un navegador web es tan simple e intuitivo que casi todos lo aprenden inmediatamente.

  • La distribución lógica hace portables los documentos HTML. Las Marcas del HTML describen a un browser qué papeles juegan las distintas partes del texto en un documento (título, elemento de la lista, etcétera) y el navegador está libre de decidir cómo (o si) visualizarlos. Esto proporciona mucha independencia de dispositivo.

  • El Hypertexto forma webs de conocimiento. Una de las características más útiles de HTML para muchas aplicaciones es la habilidad de hacer que la información "tome vida" y se refiera a otra información.

  • HTML forma un marco de trabajo para documentos mixtos. La adicción de applets y otras clases de elementos de página "áctivos" proporciona un inmenso control creativo a los desarrolladores de la "plataforma" Web.

A pesar de estas y otras muchas características que hacen al HTML tan útil, y también cool, también tiene otras serie de discapacidades que se convierten rápidamente en obstáculos para usarlo en aplicaciones de datos serias:

  • HTML es un monstruo rápidamente creciente. Fue diseñado originalmente para compartir documentos entre los científicos en la CERN. (los soportes de la CERN Conseil Europeen pour la Recherche Nucleaire, el centro para la investigación nuclear europea, a través de su Web site constantemente descrito como el laboratorio europeo para la física de partículas.) Querían texto estructurado con ciertas capacidades simples alrededor, hyperenlaces simples, control primitivo de la fuente, y quizá algunas figuras y colores bonitos, y eso es lo que crearon. Era simple, elegante, y útil. Sigue siendo útil, pero la simplicidad y la elegancia se han salido de la ventana que los desarrolladores han exigido, y los creadores de navegadores han desarrollado, las nuevas características para HTML. La especificación HTML se ha hinchado a una talla enorme con la adición de características tales como scripting, marcos, capas, vectores, formularios, hojas del estilo, objetos, applets, etc.

  • HTML se fija en piedra. Dentro de una versión determinada del estándar HTML, solamente ciertas etiquetas, como <TITLE> o <B/gt; (para boldface), son etiquetas reconocibles HTML. Si estámos trabajando con HTML, nos peleamos con etiquetas reconocidas por la especificación HTML (o nuestro navegador determinado). Si deseamos definir nuestras propias etiquetas por alguna razón, no tenemos suerte.

  • HTML está muy centrado en el navegador. Los documentos HTML son, generalmente, texto plano con marcas para proporcionar la organización de su visualización, un cierto control sobre la fuente, y algo de contenido gráfico. Son documentos escritos para que los lean los seres humanos, no para que los analicen y presenten programas del lado del cliente. Debido a esto, el HTML no es una buena opción como formato de información para los sistemas de proceso de datos automatizados.

  • HTML principalmente corrige la presentación, no el contenido. Generalmente, las etiquetas HTML describen cómo o en qué contexto mostrar un texto particular. La semántica del texto, es decir, lo que realmente significa el texto se pierde en el HTML.

. ¿Qué Significan los Datos?

Esta última deficiencia de HTML es el remache. Como los datos llegan a ser más móviles en los sistemas de proceso de datos, es necesario transferir la información y la meta-información sobre lo que significan los datos. Un número en una tabla HTML podría o no podría significar algo cuando el documento es leído por un programa. Un documento XML se puede diseñar para expresar no sólo cómo visualizar los datos, sino también qué significan los datos.

Por ejemplo, una tabla HTML puede mostrar estadísticas de un jugador de baseball:

<TABLE>
<TR ALIGN="CENTER" VALIGN="BOTTOM" BGCOLOR="#008080">
<TD><B>NO.</B></TD>
<TD><B>PLAYER</B></TD>
<TD><B>High School</B></TD>
<TD><B>AB</B></TD>
<TD><B>R</B></TD>
... 
   (etc) ...

Figura 1: una tabla HTML.
NO. PLAYER High School AB R H HR RBI AVG
12 Jonas Grumby Eaton 69 31 30 2 15 .435

Una representación en filas-columnas de estos datos está muy bien si lo que necesitamos es simplemente una visualización estática de datos en este formato determinado, pero no es una gran representación si deseamos asociar el significado de los datos en nuestra aplicación. Intentemos escribir un programa que lea el HTML de la Figura 1, extraiga la información sobre, por ejemplo, las carreras bateadas, y después hagamos algo con esa cantidad. Con HTML, eso no es fácil de hacer de una manera general. Imagínemos, que nuestro fichero de datos se parece un poco a lo que vemos en la Figura 2:

<?xml  version="1.0">
<Player>
<Name>
	<First>Jonas</First>
	<Last>Grumby</Last>&
</Name>
<Number>12</Number>
<HighSchool>Eaton</HighSchool>
<Stats>
	<Year>1997</Year>
	<AtBats>69</AtBats>
	<Runs>31</Runs>
	<Hits>30</Hits>
	<HomeRuns>2</HomeRuns>
	<RunsBattedIn>15</RunsBattedIn>
	</Stats>
</Player>

Figura 2: Fichero de datos XML

Este XML representa la misma información que en el Figura 1. Sería fácil seleccionar la estadística "RunsBattedIn" en este documento. El documento podía cambiar su estructura radicalmente, y la etiqueta <RunsBattedIn> todavía sería relativamente fácil de encontrar. El código XML anterior contiene la misma información que el código HTML de la Figura 1 pero se representa de forma que indica lo que significan los datos, no sólo cómo presentarlos.

Al igual que en el HTML, se puede asociar una hoja del estilo se puede asociar con XML, aunque el lenguaje de estilo de XML, XSL, es más poderoso y críptico que las hojas de estilo en cascada de HTML. De hecho, XSL puede convertir XML en HTML para su visualización en un navegador! El XML de arriba podría visualizarse en un navegador como aparece en la Figura 1, pero los programas del lado del cliente también podrían recoger y utilizar dicha estadística, puesto que hay una indicación (mediante la etiqueta) de lo que significan los datos.

Podríamos preguntarnos cómo sabíamos qué etiquetas utilizar para crear el fichero de ejemplo XML. ¿De dónde vienen los nombres de las etiquetas (como RunsBattedIn)? La respuesta es: Los creamos. Acabamos de inventar las etiquetas de marcas para nuestra aplicación! Crear un nuevo lenguaje de marcas es como crear cualquier otra clase de formato de fichero personalizado. Un desarrollador simplemente crea un formato de fichero que resuelva las necesidades de la aplicación. Los ficheros XML son especiales porque se adaptan a la definición XML, y los programas que los procesan pueden esperar entradas de una cierta estructura, y razonablemente peuden rechazar las entradas que no siguen esa estructura.

En el ejemplo anterior, hemos creado un nuevo sublanguage XML simplemente inventando nuevas etiquetas y usándolas consistentemente. XML también proporciona la opción de especificar un Document Type Definition (DTD), que es una especificación de qué elementos forman un documento válido. Un DTD da a un desarrollador mucho más control sobre el formato de un documento XML. No vamos a cubrir DTDs en este tutorial, pero son un concepto básico de XML.

Si pensamos que XML parece HTML, es porque son primos cercanos. XML y HTML son aplicaciones de SGML (Standard Generalized Markup Language) , que es un metalanguage -- es decir, un lenguaje para describir lenguajes. SGML es una herramienta extremadamente poderosa, flexible, y compleja, y su complejidad ha conducido a su uso sobre todo en enormes organizaciones, como gobiernos y grandes corporaciones. XML es un subconjunto de SGML que conserva la mayor potencia de SGML mientras simplifica su uso para los mortales comunes. De hecho, HTML y XML se especifican realmente como DTDs del SGML (¿Todavía te queman las siglas?)

Refiriéndonos otra vez a la figura 2, observa que XML indica lo que significan los datos, no cómo se deben visualizar. Observa también que las etiquetas ciertamente no son estándard HTML (esperemos que la etiqueta <RunsBattedIn> nunca sea parte del estándar de HTML!) Este ejemplo muestra una de las fuerzas de XML: la capacidad de definir etiquetas personalizadas para satisfacer una aplicación determinada. Finalmente, observa que el promedio de bateo no aparece en los datos XML. Esto es porque el promedio se podría calcular a partir de los otros valores.

Una de las habilidades más poderosas de XML es que, con XML, un diseñador de sistemas puede crear un lenguaje de marcas personalizado que mantenga la semántica de los datos.

Ahora que hemos visto a qué se parecen los ficheros XML, veremos como procesar datos XML en Java.

. El Document Object Model (DOM)

Los lenguajes como HTML y XML se llaman a menudo lenguajes de marcas estructurados. Esto significa que las marcas de un fichero tienen una estructura determinada que significa algo para las aplicaciones que lo procesan. Por ejemplo, los ficheros HTML comienzan con el elemento <HEAD>, que contiene un <TITLE>, que contiene texto, etcétera. Un navegador HTML visualiza la información de un fichero HTML basándose en esta estructura.

Las estructuras XML y HTML son tan simples y consistentes que es muy fácil representar cualquier documento XML o HTML como un árbol de objetos, tanto en Java como en cualquier otro lenguaje de programación. El Consorcio de la World Wide Web (W3C) ha definido un conjunto completo de objetos que se pueden utilizar para procesar documentos XML y HTML como árboles. La especificación para este conjunto de objetos se llama Document Object Model. Volvamos de nuevo a nuestro ejemplo y veamos cómo representar un documento como un árbol.

Echemos otra mirada al XML de la figura 2. Observaremos que el documento tiene una estructura jerárquica: los elementos contienen otros elementos. Por ejemplo, el elemento <Name> contiene un elemento <First> y un elemento <Last>. Esta relación "contenida" se podría representar en un diagrama de clases, según lo mostrado en la figura 3. En este diagrama, una clase Player contiene un entero Number y un String High School, y también contiene referencias a otros dos objetos, a un objeto PersonName y un objeto Statistics. Cada uno de estos objetos también contiene otros objetos.


Figura 3: Diagrama de clases.

Los documentos HTML también tienen esta estructura "contenida", pero en un documento HTML, la estructura refleja información sobre el documento (el título, las cabeceras, etcétera) en lugar de reflejar la estructura de la información representada por el documento. El documento XML anterior refleja cómo la información se relaciona con otras informaciones.

En general, podemos pensar en un documento XML (o HTML) como una estructura arborescente, con las relaciones "contenidas" en el documento que corresponden a relaciones padre-hijo en el árbol. Una posible representación gráfica de esta idea aparece en la figura 4. (Las variables determinadas que elegímos para el documento no son de notación estándar. Simplemente distinguen diversos tipos de objetos.)


Figura 4: Un árbol DOM

Así pues, un programa puede representar un documento XML como un árbol de objetos Element, cada uno de los cuales puede contener otros objetos Element y Text. El documento completo está enraizado en un sólo objeto Document. Los objetos Text contienen los datos del objeto.

El paquete Java org.w3c.dom es el estándar de "unión" de la especificación DOM en términos de los interfaces de Java (lo que significa que todos sus métodos son abstractos, y por lo tanto no tiene ninguna implementación). Varios vendedores pueden implementar las clases de este paquete de cualquier manera que deseen. IBM, por ejemplo, ha implementado este paquete en su distribución xml4j. Hay varias implementaciones de DOM, la mayoría de las cuales incluyen extensiones específicas del vendedor. Utilizaremos DOM en la aplicación de ejemplo de abajo.

. Analizadores XML DOM

Ahora que hemos definido un nuevo lenguaje, y tenemos un sistema de estructura de datos (DOM) para representar cualquier documento en este lenguaje como un árbol en memoria, sería útil tener un analizador de sintaxis que convierta automáticamente un documento XML en su árbol DOM. Una vez que tengamos la representación DOM de un documento en memoria, podemos procesar el documento como un árbol de nodos, en vez de como una serie de líneas o de símbolos. Lo qué necesitamos es un analizador de sintaxis Java que lea el fichero XML (que solamente es un fichero del texto, después de todo) y produzca un solo objeto Document que contenga un árbol de nodos DOM que representan completamente al documento.

Afortunadamente, no tenemos que salir y escribir un analizador de sintaxis desde el principio. Varias compañías e individuos han escrito analizadores de sintaxis que leen documentos XML desde ficheros o streams y producen un objeto Document DOM, que es la raíz de un árbol de objetos DOM (según lo vimos en la figura 4). El proceso completo de lectura de un fichero XML y de convertirlo en un árbol utilizable se encapsula en el analizador de sintaxis. Muchas de las implementaciones del objeto DOM también incluyen las extensiones para hace la inversa; es decir, un Document DOM se puede imprimir como XML con una sola llamada a método.

En el código de ejemplo de abajo (sí, finalmente estamos consiguiendo un ejemplo de codificación!!), hemos utilizado el analizador de sintaxis del paquete xml4j de IBM, que está disponible para uso no comercial en la site de IBM http://www.alphaWorks.ibm.com/tech/xml4j, yo considero alphaWorks como uno de los sitios más interesantes de la tecnología de Java en el Web. El paquete xml4j implementa completamente el W3C DOM, lo extiende una manera sensible pero encapsulada, y viene con una documentación copiosa, y excelente.

. Beans como Documentos XML

En el pensamiento de cómo utilizar XML con JavaBeans, decidímos que sería interesante utilizar XML como formato para la serialización de beans. Es decir decidímos crear un lenguaje de marcas que permita que un usuario cree un fichero de XML que especifique los valores para las propiedades de un JavaBean.

La clase de ejemplo que desarrollamos en este capítulo se llama XMLBeanReader. Lee un fichero XML (de un formato específico que hemos definido) y usa su contenido para crear un JavaBean e inicializar las características del bean. El nombre de la clase JavaBean y los valores de las propiedades vienen del contenido del fichero XML. Todos los métodos de esta clase son static.

Si entendemos cómo funciona este pequeño programa de ejemplo, podemos ampliarlo para que maneje relaciones de eventos, búsqueda de valores por defecto para las propiedades, o buscando la información que no está en el propio fichero XML para configurar el JavaBean. Las posibilidades son infinitas, una vez que entendamos que una estructura de datos JavaBeans se puede convertir en un fichero XML y viceversa.

La clase XMLBeanReader trabaja como el mecanismo estándar de serialización de Java, en el que se toma una secuencia de un stream de datos "plano" y se utilizan esos datos para configurar las propiedades de un JavaBean. No crea una nueva clase. Utiliza XML para ejemplarizar un JavaBean y configurar sus propiedades para una clase de JavaBean que ya exista.

. Lenguaje de Marcas JavaBean

Antes de escribir cualquier código, necesitamos definir como será nuestro sencillo dialecto de XML. Puesto que nuestra aplicación trata con JavaBeans, vamos a crear un lenguaje que permita que el usuario especifique un JavaBean y su clase, y después especifique una lista de propiedades para el JavaBean.

A pesar de algunas semejanzas, la clase XMLBeanReader que estámos a punto de ver no está de ninguna manera relacionada con el lenguaje de marcas de beans de IBM (BML está disponible en http://www.alphaWorks.ibm.com/). Una vez que entendamos lo que vamos ha hacer con el código de este capítulo, podremos abordar mejores proyectos usando BML.

Para este sencillo dialecto XML, las únicas etiquetas que necesitamos son:

  • <JavaBean>: una etiqueta que encierra una especificación de contenidos de un JavaBean

  • <Properties>: una etiqueta que encierra todos los elementos <Property> de un JavaBean particular

  • <Property>: una etiqueta que encierra el valor de una sola propiedad

Ahora imaginemos, que teníamos uan clase Player, que era un JavaBean con cuatro propiedades:

  • int Number: el número del jugador

  • String HighSchool: El nombre del Instrituro del Jugador

  • PersonName Name: un JavaBean de la clase PersonName que es el nombre del jugador.

  • Statistics Stats: un JavaBean de la clase Statistics que contiene las estadísticas de bateo del jugador en un año en particular.

Oserva que dos de los valores de las propiedades son JavaBeans a su vez. El código fuente para las tres clases JavaBeans que vamos a utilizar lo puedes encontrar en:

Dando la clase JavaBean que acabamos de definir (Player), las etiquetas que hemos definido arriba, y los datos de la figura 2, podríamos expresar el JavBean en XML en término de sus propiedades, de esta forma:

<?xml version="1.0"?>
<JavaBean CLASS="Player">
    <Properties>
        <Property NAME="Number">12</Property>
        <Property NAME="HighSchool">Eaton</Property>
        <!-- 
        Notice that the value for the properties "Name" 
        and** "Stats" are themselves 
        JavaBeans!** Notice also that comments 
        in XML files look** just like comments 
        in HTML 
        files.-->

        <Property NAME="Name">
            <JavaBean CLASS="PersonName">
                <Properties>
                    <Property NAME="First">Jonas</Property>
                    <Property NAME="Last">Grumby</Property>
                </Properties>
            </JavaBean>
        </Property>
        
        <Property NAME="Stats">
            <JavaBean CLASS="Statistics">
                <Properties>
                    <Property NAME="Year">1997</Property>
                    <Property NAME="AtBats">69</Property>
                    <Property NAME="Runs">31</Property>
                    <Property NAME="Hits">30</Property>
                    <Property NAME="HomeRuns">2</Property>
                    <Property NAME="RunsBattedIn">15</Property>
                </Properties>
            </JavaBean>
        </Property>
    </Properties>
</JavaBean>

Figura 5: El JavaBean Player en formato XML.

Lo primero que observaremos en el código de arriba es que hay strings entre comillas dentro de las etiquetas, de esta forma:

<JavaBean CLASS="Player">

Estas cadenas se llaman atributos, y si has escrito HTML, los habrás utilizado. Aparecen en etiquetas como los hiperenlaces (<A HREF="... ">) y los atributos de las imágenes (<IMG el SRC="... ">.) Los atributos simplemente son otra forma de asociar datos a un nodo de un Element DOM. El método Element.getAttribute() devuelve un atributo de un Element con un nombre específico. No hay reglas duras-y-rápidas sobre cuándo incluir datos en un atributo y cuándo ponerlos en el objeto Text dentro del Element. Tendemos a utilizar los atributos para información estructural (clases, nombres de la propiedades, etcétera) y Text para ejemplares de datos. Debemos utilizar lo que consideremos más fácil.

. Crear JavaBeans desde XML

La clase XMLBeanReader (codigo fuente en XMLBeanReader.java es bastante directa. El método main() (líneas 400 a 415) simplemente llama al método estático readXMLBean(), pasándole el nombre del fichero de entrada. El resultado devuelto por readXMLBean() es un JavaBean cuya clase y contenido corresponden con lo que había en el fichero XML. main() entonces chequea para ver si el JavaBean recien creado tiene una llamada al método print() y, si es así, main() lo llama.

readXMLBean() (líneas 377 a 395) crea un analizador de sintaxis XML y lo invoca sobre el fichero de entrada. El resultado del método readStream() del analizador de sintaxis es el árbol del documento, que, si se dibuja, se parecería al de la figura 4. Entonces pasa la parte superior del Element del árbol de documento (la etiqueta que debe ser JavaBean) al método estático instantiateBean(), que es donde se hace todo el trabajo serio. El resultado de instantiateBean() es el JavaBean que creó el método.

instantiateBean() (líneas 269 a 294) crea un JavaBean desde un árbol DOM con un elemento <JavaBean> en la parte superior. Primero, crea un objeto del tipo indicado por el atributo CLASS del elemento <JavaBean>. Luego encuentra el nodo <Properties>, que es un hijo del nodo superior (<JavaBean>). Dentro de este <Properties> puede haber varios <Property>, cada uno de los cuales corresponde a una propiedad del JavaBean. Por cada <Property> Element (entre los hijos de <Properties>), instantiateBean() llama a setProperty(), pasandole el nombre de la propiedad, el descriptor de la propiedad (obtenido aplicando java.beans.Introspector al JavaBean creado), el Element que corresponde a la propiedad, y el nuevo bean. Cuando se ha terminado este proceso, se ha creado y se ha inicializado el JavaBean, y se puede volver al llamador.

El método setProperty() (líneas 048 a 249) tiene cuidado de seleccionar una propiedad de un JavaBean. Maneja propiedades regulares e indexadas por separado (ignorando las propiedades indexadas, por el momento). En el caso (usual) de una propiedad no indexada, setProperty() primero busca todos los hijos <Property> por cada nodo Text o elemento <JavaBean>, y registra lo que encuentra para su uso posterior. También le pide a PropertyDescriptor el método setter de la propiedad.

El resto de setProperty() concierne a la figuración de los argumentos que pasar al método de setter. Hay algunas condiciones posibles, que dependen del tipo de la propiedad, o sobre los argumentos previstos del método setter:

  • El tipo de la propiedad es primitivo. (Líneas 110 a 147.) Todos los tipos primitivos puden construirse desde un String, así que si el tipo de una propiedad es primitivo ( boolean, byte, int, long, float, o double), setMethod simplemente construye un objeto del tipo apropiado utilizando un constructor que acepta un String como argumento y pasa el valor del texto al Element. Las propiedades del tipo primitivo char se manejan como un caso especial, puesto que hemos decidido codificarlas como su valor entero, y no pueden no ser leídas y construidas desde Strings. El objeto que el método construye se utiliza como el argumento al método setter.

  • A aparecido un elemento <JavaBean> como un hijo de <Property>, dicha propiedad debe ser un JavaBean. (líneas 168 a 191.) En este caso, el argumento que deseamos pasar al método setter es realmente un JavaBean. Necesitamos ejemplarizar ese JavaBean antes de poder pasarlo al setter, y lo hacemos mediante llamadas recursivas a instantiateBean(), pasándole el elemento hijo <JavaBean>. El objeto que resulta (JavaBean) se pone en la lista de argumentos para el setter.

  • El método setter para la propiedad toma como único argumento un String. (Líneas 193 a 203.) Este es un caso sencillo. La lista de argumentos para el setter sólo contiene el Element text de Property.

  • El método setter para la propiedad acepta como único argumento un objeto que pueda ser construido desde un String. (líneas 205 a 222.) En este caso, setMethod() hace exactamente lo que se hacía en el caso primitivo: construye un objeto del tipo apropiado, usando el texto del Element como el argumento del constructor, y después pone este nuevo objeto en la lista de argumentos (setterArgs) para el setter.

Si no se cumple ninguna de estas condiciones, setProperty() no es capaz de fijar la propiedad, y vuelve sin hacer nada. (Probablemente debería lanzar una IllegalArgumentException, pero esto es sólo un programa de demostración.)

Ejecutando el método main() del fichero class, y pasándole el fichero fuente XML que vimos en la Figura 5, produce un JavaBean en ejecución con todas sus propiedades fijadas a los valores que vinieron (originalmente) desde el XML, incluyendo las propiedades cuyos valores son JavaBeans. Podemos ver la salida de este programa en Example.html. Veremos que el bean Stadistics señala de hecho sus propiedades fijadas correctamente.

. Conclusión

En un espacio muy pequeño, hemos cubierto una cantidad enorme de terreno. Hemos leído sobre qué es XML, y qué puede hacer que HTML no puede. El ejemplo XML de una estadística de bateo mostró cómo la estructura XML se puede utilizar para reflejar el significado de los datos, no su presentación. Entonces leímos sobre el interface programático estándar de XML, el modelo del objeto del documento DOM, y después vimos un ejemplo de DOM y XML en acción, siendo utilizado para crear e inicializar un nuevo ejemplar de JavaBean.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.