Customizações de BindGen
Nesta seção, você aprenderá como customizar a operação BindGen para controlar a representação XML de dados, alterar o estilo de nomes e espaços de nomes e controlar alguns aspectos da estrutura do esquema.
Customizando a Operação BindGen
BindGen suporta customizações extensivas para todos os aspectos de ligação e geração de esquema. O conjunto de customizações a serem aplicadas é passado para BindGen como um documento XML, com elementos aninhados que espelham a estrutura de seu código Java. A Listagem 6 fornece um exemplo simples:
Listagem 6. Exemplo de Customizações Simples
<custom>
<package name="org.jibx.starter" property-access="true">
<class name="Address" includes="street1 street2 city state postCode country"/>
<class name="Item" excludes="description"/>
</package>
</custom> |
Esse exemplo funciona com um único pacote de código Java, portanto, a Listagem 6 usa apenas um elemento <package> filho do elemento <custom> raiz. <package> e <class> são elementos de customização que usam atributos de nome que são relativos a qualquer elemento <package> de anexação, portanto, no exemplo da Listagem 6 somente um nome de classe simples é necessário para cada elemento <class> . <package> são elementos que podem ser aninhados dentro de outro, portanto, se você estiver lidando com classes em uma hierarquia de pacotes, é fácil tratar quaisquer opções usando elementos <package> aninhados. A estrutura aninhada é especialmente conveniente, pois muitos atributos de customização são herdados através do aninhamento de elemento, como discutirei posteriormente nesta seção. Usar aninhamento é opcional, no entanto — você pode ignorar os elementos <package> completamente e usar os elementos <class> com nomes de classe completos diretamente, se preferir.
Um arquivo de customização é passado para BindGen como um parâmetro da linha de comando usando o formato -c file-path. Customização sempre são opcionais e você nunca precisa usar um arquivo de customização, a menos que queira alterar o comportamento padrão de BindGen.
Controlando como BindGen Funciona com seu Código
BindGen realiza uma tarefa razoável com sua manipulação padrão de classes Java, mas há limites sobre o que pode ser feito sem a orientação do usuário.
Por exemplo, a manipulação padrão é incluir cada campo na representação XML, exceto para campos estáticos, temporários ou finais.
Essa abordagem funciona bem para classes que representam objetos de dados simples; no entanto, se suas classes incluírem informações de estado ou valores computados, você pode acabar com uma representação XML que inclui valores que você preferiria não expor fora da classe.
Customizações permitem que você controle de duas maneiras o que BindGen usa na representação XML. Primeiro, é possível alternar facilmente para usar métodos de acesso de estilo bean getXXX(), setXXX() e isXXX() em vez de acessar os campos diretamente. Segundo, você pode optar por listar os valores que você deseja incluir na representação XML para uma classe ou listar os valores que você deseja excluir. As customizações da Listagem 6 demonstram ambas as técnicas.
 |
Conversões Unidirecionais
Este tutorial usa JiBX para conversões bidirecionais entre estruturas de dados Java e documentos XML. BindGen também suporta conversões unidirecionais, que podem ser mais convenientes em alguns casos. Por exemplo, as classes de objeto de valor são geralmente imutáveis e definem somente campos final e lêem os métodos de acesso ("get"). Isso dificulta o uso das classes de objeto de valor para conversões bidirecionais com BindGen. Se, em vez disso, você indicar a BindGen para gerar uma conversão somente de saída, funcionará bem com os campos ou as propriedades, o que você preferir. Para gerar uma conversão unidirecional, use direction="output" ou direction="input" no elemento raiz <custom> das customizações.
|
|
O elemento <package> na Listagem 6 usa um atributo property-access="true" para indicar a BindGen para procurar propriedades de estilo bean definidas por métodos de acesso públicos não-estáticos, em vez de campos, ao determinar quais valores incluir na representação XML. Esse atributo é um exemplo de uma configuração de customização herdada, que se aplica a tudo aninhado dentro do elemento com o atributo. No exemplo da Listagem 6 , a configuração se aplica aos dois elementos <class> aninhados. Também se aplica a todas as outras classes do pacote, mesmo nenhum elemento de customização <class> estando presente para essas outras classes. Além de determinar como os valores são localizados a partir da representação da classe, a configuração property-access também controla como os valores são acessados pelo código JiBX gerado — diretamente a partir dos campos ou chamando os métodos de acesso.
O primeiro elemento <class> da Listagem 6 usa um atributo includes="street1 street2 city state postCode country" para lista os valores específicos da classe que BindGen precisa para incluir na representação XML. O segundo elemento <class> da listagem usa um atributo excludes="description" , que lista valores a serem excluídos da representação XML. Como você está usando acesso de propriedade em vez de acesso de campo para valores, esses nomes são correspondidos com propriedades definidas pelos métodos de acesso get/set/is. Se você estivesse usando campos, os nomes dos valores seriam correspondidos com nomes de campos.
O destino Ant custgen1 executa BindGen usando as customizações da Listagem 6 . Esse destino é uma alternativa para o destino bindgen mostrado anteriormente, portanto, para executar a construção completa você usaria a linha de comando Ant: ant compile custgen1 bind. A Listagem 7 mostra a definição do tipo de item a partir do esquema gerado quando esse destino é executado:
Listagem 7. Fragmento de Saída do Esquema Customizado
<xs:element name="item" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:string" name="id" minOccurs="0"/>
</xs:sequence>
<xs:attribute type="xs:int" use="required" name="quantity"/>
<xs:attribute type="xs:float" use="required" name="price"/>
</xs:complexType>
</xs:element> |
Você pode ver da Listagem 7 que o valor da descrição agora está faltando na representação do esquema, conforme especificado pelas customizações.
É necessário usar um documento XML diferente como entrada ao usar essa customização, pois o elemento <description> presente no XML original não é mais usado. O destino Ant run1 executa o programa de teste usando uma entrada data1.xml e gerando out1.xml como saída. Você também pode executar toda a sequência, da compilação do código de origem até a execução do programa de teste, com o destino Ant custom1 .
Controlando a Criação da Instância
A criação da instância durante a desserialização também pode ser controlada usando-se customizações. Por padrão, JiBX espera ter um construtor sem argumento (padrão) definido para cada classe (que o compilador Java gera automaticamente, se você não definir nenhum outro construtor). Quando uma nova instância da classe é necessária durante a desserialização, JiBX usa esse construtor sem argumento para criar a instância. Se algumas de suas classes definirem somente construtores com argumentos, você pode usar customizações de BindGen para torná-los usáveis por JiBX. Uma maneira de fazer isso é definindo um método de factory para ser usado para a criação de instâncias da classe, usando um atributo factory="xxx" no elemento de customizações <class> para fornecer o nome completo (com as informações de pacote e classe líder) de um método estático que retorna uma instância da classe. Você também pode simplesmente incluir add-constructors="true" no elemento raiz <custom> , que irá gerar uma ligação que inclui construtores sem argumento em classes, conforme necessário. Essa segunda abordagem funciona bem para classes de dados normais, mas você ainda precisará fornecer um factory para qualquer interface ou classes abstratas (que nunca podem ser construídas diretamente). É claro, se você estiver gerando uma ligação somente de saída (consulte a barra lateral Conversões Unidirecionais ), a criação de instância não é um problema e você não precisa se preocupar com os construtores.
Outras Customizações para Trabalhar com Classes de Entrada
BindGen suporta muitas outras customizações usadas para controlar como funciona com as classes de entrada Java. Por exemplo, se você usar uma convenção de nomenclatura para seus nomes de campos Java, pode configurar BindGen para ignorar strings específicas de prefixo ou sufixo usando os atributos strip-prefixes ou strip-suffixes . (Portanto, para ignorar prefixos m_ e s_ , por exemplo, você usaria strip-prefixes="m_ s_"). Essas modificações nos nomes de campos são aplicadas antes dos campos serem correspondidos a nomes de valores usados em outras customizações e naturalmente também se aplicam quando nomes XML são gerados a partir dos nomes de campos.
Você também pode customizar a manipulação de campos individuais ou propriedades bean de uma classe, usando elementos
<value> aninhados. Você verá como trabalhar com esses elementos de customização de valor em um exemplo posterior.
Controlando a Representação XML
Além de controlar como BindGen interpreta seu código Java, você pode usar customizações para controlar a representação de dados XML. Essas customizações XML incluem a representação real (como um elemento ou um atributo) de valores, a ordem e os nomes dos elementos e atributos, seja o valor opcional ou necessário, e mais.
O exemplo de customização anterior da Listagem 6 demonstra uma customização XML no formato do atributo includes="street1 street2 city state postCode country" usando no primeiro elemento <class> . Discuti como isso seleciona os valores da classe incluído na representação XML. Também controla a representação XML sendo que a ordem na qual os valores são listados torna-se a ordem na qual são expressados na representação XML. Esse não é um problema significativo para atributos (que sempre são considerados sem ordem em XML), mas é importante para elementos.
Se você não especificar a ordem dos valores usando um atributo includes na customização <class> , BindGen gera os valores na ordem em que são fornecidos usando reflexo Java nas classes. Para a maioria dos compiladores Java e JVMs, essa ordem de reflexo corresponderá a ordem das definições no código de origem Java. No entanto, os compiladores Java e JVMs não são necessários para preservar essa ordem do código de origem, portanto, alguns compiladores ou JVMs podem fazer com que BindGen altere a ordem dos elementos filhos. Se quiser ter certeza de que a representação XML sempre será a mesma, independentemente do compilador Java e da JVM usados, o atributo includes fornece uma maneira fácil de corrigir a ordem.
Você também pode controlar a representação XML de um valor usando o atributo includes . BindGen permite que os caracteres iniciais do sinalizador sejam usados em cada nome da lista para indicar a representação: @ para um atributo e / para um atributo. Portanto, se você alterar a customização da Listagem 6 para includes="street1 street2 city state @postCode country", a representação do valor do código post é alterado de um elemento filho para um atributo.
Controlando Status Necessário
Controlar se um valor for considerado opcional ou necessário é outra fácil customização usando os seguintes atributos do elemento
<class> : requireds e optionals . Como com o atributo includes , você pode preceder nomes nas listas requireds e optionals por um caractere sinalizador para indicar se devem ser expressados como um elemento filho ou um atributo.
Por padrão, BindGen trata todos os valores primitivos e valores de objeto simples (classes com tipos equivalentes XML diretos, diferentes de
String) como atributos e trata todos os valores de objeto complexos como elementos filhos.
Todos os valores primitivos são tratados conforme necessário e todos os valores de objeto como opcionais. Além de substituir esses padrões no nível de customização <class> usando os elementos includes, requiredse optionals , é possível alterar a representação padrão para usar elementos para todos os valores configurando um atributo value-style="element" em qualquer nível de customizações (elemento <custom>, <package> ou <class> ). Você também pode usar o atributo require para controlar quais tipos devem ser tratados como valores necessários no XML:
require="none" torna tudo opcional.
require="primitives" é o padrão, tornando somente os valores primitivos necessários.
require="objects" inverte o padrão, tornando os primitivos opcionais e os tipos de objetos necessários.
require="all" trata todos os valores necessários por padrão.
A Listagem 8 mostra o arquivo de customização custom2.xml do diretório dwcode1 do download do tutorial, ilustrando diversos recursos discutidos nesta seção:
Listagem 8. Customizando Pedido, Status Necessário e Representação
<custom property-access="true">
<package name="org.jibx.starter">
<class name="Address" includes="street1 street2 city @state @postCode country"
requireds="street1 city"/>
<class name="Customer" includes="customerNumber firstName lastName"
requireds="lastName firstName /customerNumber"/>
<class name="Item" excludes="description" requireds="@id quantity price"/>
<class name="Order" requireds="/orderNumber customer billTo shipping orderDate"/>
</package>
</custom> |
Você pode tentar esse conjunto de customizações usando o destino Ant custgen2 (ant compile custgen2 bind, para executar a construção completa). A Listagem 9 mostra as partes selecionadas do esquema gerado usando essas customizações, mostrando o pedido resultante, o status necessário (com minOccurs="0" para elementos opcionais, que são necessários por padrão no esquema e use="required" para atributos necessários, que são opcionais por padrão no esquema) e representação do elemento ou atributo:
Listagem 9. Esquema Gerado Usando Customizações
<xs:complexType name="order">
<xs:annotation>
<xs:documentation>Order information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element type="xs:long" name="orderNumber">
<xs:annotation>
<xs:documentation>Get the order number.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:long" name="customerNumber"/>
<xs:element type="xs:string" name="firstName"/>
<xs:element type="xs:string" name="lastName"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
</xs:sequence>
<xs:attribute type="xs:date" use="required" name="orderDate"/>
<xs:attribute type="xs:date" name="shipDate"/>
<xs:attribute type="xs:float" name="total"/>
</xs:complexType>
<xs:element type="tns:order" name="order"/>
<xs:complexType name="address">
<xs:annotation>
<xs:documentation>Address information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element type="xs:string" name="street1"/>
<xs:element type="xs:string" name="street2" minOccurs="0"/>
<xs:element type="xs:string" name="city"/>
<xs:element type="xs:string" name="country" minOccurs="0"/>
</xs:sequence>
<xs:attribute type="xs:string" name="state"/>
<xs:attribute type="xs:string" name="postCode"/>
</xs:complexType> |
Após compilar a ligação usando a tarefa Ant bind , você pode testar isso usando a tarefa
run2 que aceita o documento de teste
data2.xml como entrada e gera um out2.xml de saída. Você também pode executar a sequência completa da compilação ao teste com o destino
custom2
. A Listagem 10 mostra o documento de teste:
Listagem 10. Testar Customizações de Correspondência de Documento
<order orderDate="2008-10-18" shipDate="2008-10-22" xmlns="http://jibx.org/starter">
<orderNumber>12345678</orderNumber>
<customer>
<customerNumber>5678</customerNumber>
<firstName>John</firstName>
<lastName>Smith</lastName>
</customer>
<billTo state="WA" postCode="98059">
<street1>12345 Happy Lane</street1>
<city>Plunk</city>
<country>USA</country>
</billTo>
<shipping>PRIORITY_MAIL</shipping>
<shipTo state="WA" postCode="98034">
<street1>333 River Avenue</street1>
<city>Kirkland</city>
</shipTo>
<item quantity="1" price="5.99" id="8394983498512"/>
<item quantity="2" price="9.50" id="9912349050499"/>
<item quantity="1" price="8.95" id="1293000488209"/>
</order> |
Compare a Listagem 10 ao documento de teste original, mostrado na Listagem 3, para ver como suas customizações alteraram a representação XML dos dados (inclusive alterando o formato das representações dos itens de linha para elementos vazios, uma representação muito mais compacta do que a original).
Controlando Nomes e Espaços de Nome
Os nomes Java geralmente usam um estilo "caixa alternante": os nomes são, em sua maioria, em minúsculas, mas a letra inicial de cada palavra é maiúscula. Para o nomes de campo ou propriedade, a letra maiúscula inicial aplica-se somente a palavras após a primeira (resultando em nomes como postCode e customerNumber). Os nomes XML não são padronizados e diversos estilos diferentes são comumente usados. Eles incluem o estilo camelcase com minúscula inicial (o estilo do campo e do nome da propriedade), caixa alternante com um caractere maiúsculo inicial (o estilo do nome da classe Java), estilo de separador com hífen (palavras separadas por hifens), estilo de separador com ponto (palavras separadas por pontos) e estio de separador de sublinhado (palavras separadas por sublinhados).
BindGen assume o estilo caixa alternante para nomes XML por padrão, mas você pode alterar isso facilmente, configurando um atributo name-style em qualquer nível de customização (elemento <custom>, <package> ou <class> ). Os valores permitidos para esse atributo correspondem os estilos XML diferentes listados acima:
camel-case (o padrão)
upper-camel-case
hyphenated
dotted
underscored
Você também pode configurar o nome XML para um valor usando uma customização especificamente para esse valor.
Usar uma customização de valor individual fornece controle integral sobre como esse valor será acessado e como ele será representado em XML.
A Listagem 11 fornece dois exemplos de como usar elementos de customização para valores individuais, baseados no mesmo código de exemplo visto nos exemplos anteriores:
Listagem 11. Customizando Nomes e Namespace
<custom property-access="true" name-style="hyphenated" namespace="http://jibx.org/custom"
namespace-style="fixed">
<package name="org.jibx.starter">
<class name="Address" includes="street1 street2 city @state @postCode country"
requireds="street1 city"/>
<class name="Customer" includes="customerNumber firstName lastName"
requireds="lastName firstName /customerNumber"/>
<class name="Item" excludes="description" requireds="@id quantity price"/>
<class name="Order" requireds="orderNumber customer billTo shipping orderDate">
<value property-name="orderNumber" element="order-num"/>
<value property-name="items" item-name="line-item" element="order-items"/>
</class>
</package>
</custom> |
A customização do primeiro valor na Listagem 11 é para a propriedade orderNumber , dentro do elemento <class name="Order"...> . Usando um atributo element="order-num" , a customização orderNumber indica a BindGen para expressar o valor como um elemento, em vez do formato do atributo padrão usado para um valor primitivo. A segunda customização é para a propriedade de coleta items . Essa customização usa os atributos item-name e element . O atributo item-name controla o nome usado para os valores individuais representados pela coleta, enquanto o atributo element força o uso do nome fornecido como um elemento wrapper em torno dos valores na coleta.
 | XML sem Espaços de Nomes
Todos os exemplos do tutorial usam espaços de nomes XML, pois o uso dos espaços de nomes é geralmente considerado uma boa prática para troca de dados. Se quiser trabalhar com XML sem espaços de nomes, você pode usar um atributo namespace-style="none" em qualquer nível das customizações para desativar espaços de nomes completamente para todos os componentes aninhados.
|
|
As customizações da Listagem 11 também definem o namespace a serem usados em documentos XML.
Os exemplos anteriores dependem da manipulação de espaços de nomes de BindGen padrão, que é derivar a URI do namespace usada na representação XML do código Java do pacote Java.
Essa manipulação padrão converteu o pacote org.jibx.starter para a URI do namespace http://jibx.org/starter. Na Listagem 11, o namespace é customizado incluindo um par de atributos
—
namespace="http://jibx.org/custom" e namespace-style="fixed" — no elemento raiz <custom> . O primeiro desses atributos define o namespace base, enquanto que o segundo evita o comportamento normal da modificação do namespace baseado no pacote Java. Esses atributos são ambos herdados através do aninhamento dos elementos de customização, portanto, eles podem ter sido colocados no elemento <package> em vez do elemento <custom> .
Você pode testar as customizações da Listagem 11 usando o destino Ant custgen3 para a ligação e geração do esquema e o destino run3 para executar um teste (após usar o destino bind padrão para executar o compilador de ligação JiBX — ou simplesmente use o destino full3 para realizar toda a sequência). A Listagem 12 mostra o documento de entrada usado com o código de teste:
Listagem 12. Amostra de XML com Nomes e Namespace Customizados
<order order-date="2008-10-18" ship-date="2008-10-22" xmlns="http://jibx.org/custom">
<order-num>12345678</order-num>
<customer>
<customer-number>5678</customer-number>
<first-name>John</first-name>
<last-name>Smith</last-name>
</customer>
<bill-to state="WA" post-code="98059">
<street1>12345 Happy Lane</street1>
<city>Plunk</city>
<country>USA</country>
</bill-to>
<shipping>PRIORITY_MAIL</shipping>
<ship-to state="WA" postCode="98034">
<street1>333 River Avenue</street1>
<city>Kirkland</city>
</ship-to>
<order-items>
<line-item quantity="1" price="5.99" id="AC4983498512"/>
<line-item quantity="2" price="9.50" id="IW2349050499"/>
<line-item quantity="1" price="8.95" id="RC3000488209"/>
</order-items>
</order> |
Se você comparar a Listagem 12 com a amostra da Listagem 10 , você verá como a representação foi alterada pelas customizações mais recentes.
Customizando as Representações do Esquema
Agora você viu como as customizações de BindGen podem alterar a representação XML de seus dados Java. As customizações também podem ser usadas para controlar alguns aspectos da estrutura real do esquema.
Lembre-se de que BindGen usa como padrão as definições aninhadas na preferência para tipos e elementos globais.
Se você rever o esquema gerado na Listagem 9 , você verá essa estrutura de aninhamento. O esquema usa somente três definições globais: os tipos complexos address eorder e o elemento order . As outras classes da estrutura de dados Java (Customer, Item e Shipping) são referidas, cada uma, em somente um ponto da classe Order , portanto, as definições de tipo correspondente são integradas diretamente na definição de tipo de esquema order .
É possível alterar o estilo do esquema usando um atributo force-mapping="true" em qualquer um dos elementos de customização aninhados. A Listagem 13 mostra o arquivo de customizações custom4.xml, que inclui essa alteração nas customizações de custom2.xml correspondentes ao esquema gerado na Listagem 9 :
Listagem 13. Customização para a Estrutura do Esquema
<custom property-access="true" force-mapping="true">
<package name="org.jibx.starter">
<class name="Address" includes="street1 street2 city @state @postCode country"
requireds="street1 city"/>
<class name="Customer" includes="customerNumber firstName lastName"
requireds="lastName firstName /customerNumber"/>
<class name="Item" excludes="description" requireds="@id quantity price"/>
<class name="Order" requireds="/orderNumber customer billTo shipping orderDate"/>
</package>
</custom> |
A Listagem 14 mostra a estrutura do esquema resultante (gerado como starter.xsd executando o destino Ant custgen4 ). Essa versão do esquema representa a mesma estrutura do documento XML que o esquema da Listagem 9 , mas inclui definições de tipos diferentes que correspondem a cada classe Java.
Listagem 14. Estrutura do Esquema Customizado
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://jibx.org/starter" elementFormDefault="qualified"
targetNamespace="http://jibx.org/starter">
<xs:simpleType name="shipping">
<xs:annotation>
<xs:documentation>Supported shipment methods. The "INTERNATIONAL" shipment
methods can only be used for orders with shipping addresses outside the U.S., and
one of these methods is required in this case.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
...
</xs:restriction>
</xs:simpleType>
<xs:complexType name="item">
<xs:annotation>
<xs:documentation>Order line item information.</xs:documentation>
</xs:annotation>
<xs:sequence/>
<xs:attribute type="xs:string" use="required" name="id"/>
<xs:attribute type="xs:int" use="required" name="quantity"/>
<xs:attribute type="xs:float" use="required" name="price"/>
</xs:complexType>
<xs:element type="tns:order" name="order"/>
<xs:complexType name="address">
<xs:annotation>
<xs:documentation>Address information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element type="xs:string" name="street1"/>
<xs:element type="xs:string" name="street2" minOccurs="0"/>
<xs:element type="xs:string" name="city"/>
<xs:element type="xs:string" name="country" minOccurs="0"/>
</xs:sequence>
<xs:attribute type="xs:string" name="state"/>
<xs:attribute type="xs:string" name="postCode"/>
</xs:complexType>
<xs:complexType name="customer">
<xs:annotation>
<xs:documentation>Customer information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element type="xs:long" name="customerNumber"/>
<xs:element type="xs:string" name="firstName"/>
<xs:element type="xs:string" name="lastName"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="order">
<xs:annotation>
<xs:documentation>Order information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element type="xs:long" name="orderNumber">
<xs:annotation>
<xs:documentation>Get the order number.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element type="tns:customer" name="customer"/>
<xs:element type="tns:address" name="billTo"/>
<xs:element type="tns:shipping" name="shipping"/>
<xs:element type="tns:address" name="shipTo" minOccurs="0"/>
<xs:element type="tns:item" name="item" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute type="xs:date" use="required" name="orderDate"/>
<xs:attribute type="xs:date" name="shipDate"/>
<xs:attribute type="xs:float" name="total"/>
</xs:complexType>
</xs:schema> |
Os esquemas do tipo mostrado na Listagem 14, chamados de esquemas de estilo "Veneziana", são populares para uso com definições de estrutura XML complexas.
Separando cada definição de tipo, esse estilo de esquema permite reutilizar facilmente as estruturas de componentes ao modificar ou estender um esquema. A flexibilidade do estilo Veneziana provavelmente não é importante se você simplesmente planejar usar seu código Java como a base para quaisquer mudanças adicionais (retornando BindGen toda vez que seu código for alterado), mas pode ser bom se você tiver a intenção de usar o esquema como base para desenvolvimento adicional.
|