Hacer JavaBeans Móviles e interoperables con XML
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.
Tutoriales
