Example 3: More extensive customizations

# Example 3: More extensive customizations |

JiBX Basics Overview Getting Started Binding Compiler Binding on Load Runtime Extras Building JiBX Maven Contributing License News and Status Support FAQ Mailing Lists Bugs User Comments Sponsors Start from Code Start from Code BindGen Example Code Example 1 Example 2 Example 3 Example 4 Customizations Reference SchemaGen Jibx2Wsdl Examples Customizations Start from Schema Start from Schema CodeGen Schema Datatype Handling Example Code Default Generation Simple Customizations More Customizations Modular Generation Customizations Reference Extensions Reference Binding Definition Binding Tutorial A basic binding Binding extras Structure mapping Collections and arrays Using mappings Advanced binding Method hooks Custom code Precompiled Bindings Definition details Definition contexts Conversions Date/time conversions XML summary <binding> element <include> element <format> element <namespace> element <mapping> element <value> element <structure> element <collection> element Attribute groups Usage API Runtime JavaDocs Subprojects Eclipse Plug-in Introduction Install Usage JiBX/WS Axis2 Usage JiBX/OTA Schema Library | ### Going further with customizations The Example 2 customizations showed some basic modifications to CodeGen default behavior. The third example goes further, using custom2.xml:
    <schema-set prefer-inline="true" generate-all="false" package="org.ota.air"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        repeated-type="array" enumeration-type="simple"
        type-substitutions="xs:integer xs:int xs:decimal xs:float">
      <name-converter strip-prefixes="OTA_"
          strip-suffixes="Type AttributeGroup Group Attributes"/>
      <class-decorator
          class="org.jibx.schema.codegen.extend.CollectionMethodsDecorator"/>
      <schema-type type-name="dateTime" java-class="org.joda.time.DateTime"
          serializer="org.jibx.runtime.JodaConvert.serializeUTCDateTime"
          deserializer="org.jibx.runtime.JodaConvert.deserializeUTCDateTime"/>
      <schema-type type-name="date" format-name="LocalDate.default"/>
      <schema-type type-name="time" format-name="LocalTime.local"/>
      <schema name="OTA_AirLowFareSearchRQ.xsd" includes="OTA_AirLowFareSearchRQ">
        <element name="OTA_AirLowFareSearchRQ" class-name="LowFareSearchRequest">
          <element path="**" name="AlternateLocationInfo" ignore="true"/>
          <element path="**" name="SpecificFlightInfo" ignore="true"/>
          <element path="**" name="ProcessingInfo" ignore="true"/>
        </element>
      </schema>
      <schema name="OTA_AirLowFareSearchRS.xsd" includes="OTA_AirLowFareSearchRS">
        <element name="OTA_AirLowFareSearchRS" class-name="LowFareSearchResponse"/>
      </schema>
      <schema name="OTA_AirCommonTypes.xsd">
        <complexType name="FareType">
          <element path="**" name="Taxes" ignore="true"/>
          <element path="**" name="Fees" ignore="true"/>
          <element path="**" name="FareConstruction" ignore="true"/>
          <element path="**" name="UnstructuredFareCalc" ignore="true"/>
        </complexType>
        <complexType name="FareInfoType">
          <element path="**" name="Date" ignore="true"/>
          <element path="**" name="FareInfo" ignore="true"/>
        </complexType>
        <complexType name="PricedItinerariesType">
          <attribute path="**" name="OriginDestinationRefNumber"
              value-name="refNumber"/>
        </complexType>
        <complexType name="PricedItineraryType">
          <element path="**" name="AirItinerary" ignore="true"/>
          <element path="**" name="AirItineraryPricingInfo"
              value-name="pricingInfo"/>
          <element path="**" name="Notes" ignore="true"/>
          <element path="**" name="TicketingInfo" ignore="true"/>
        </complexType>
        <complexType name="AirItineraryPricingInfoType">
          <element path="**" name="PTC_FareBreakdowns" ignore="true"/>
        </complexType>
        <complexType name="TravelerInformationType">
          <element path="**" name="AirTraveler" ignore="true"/>
        </complexType>
        <complexType name="TravelerInfoSummaryType">
          <element path="**" name="PriceRequestInformation" ignore="true"/>
        </complexType>
      </schema>
      <schema name="OTA_AirPreferences.xsd">
        <complexType name="AirSearchPrefsType">
          <element path="**" name="VendorPref" ignore="true"/>
          <element path="**" name="FlightTypePref" ignore="true"/>
          <element path="**" name="EquipPref" ignore="true"/>
          <element path="**" name="CabinPref" ignore="true"/>
          <element path="**" name="TicketDistribPref" ignore="true"/>
        </complexType>
      </schema>
      <schema name="OTA_CommonTypes.xsd" excludes="ConnectionType">
        <complexType name="SourceType">
          <element path="**" name="Position" ignore="true"/>
          <element path="**" name="BookingChannel" ignore="true"/>
        </complexType>
      </schema>
    </schema-set>
These customizations effect both the form of the generated code and the actual schema structure used to drive the code and binding generation. On the root <schema-set> element, the `repeated-type="array"` attribute changes the representation of repeated values from the default Java 5 typed lists (inappropriately called "generics") to arrays, and the `enumeration-type="simple"` attribute changes the representation of enumerations from the default Java 5 `enum` format to custom type-safe enumerations. Together these changes make the generated code compatible with pre-Java 5 JDKs (you could also do this by using `repeated-type="list"` in place of `repeated-type="array"`, generating simple untyped lists). The `type-substitutions="xs:integer xs:int xs:decimal xs:float"` attribute gives pairs of types, with the second type in each pair substituted for the first wherever referenced in the schema definitions. This allows you to easily replace a simple type with an awkward Java representation (such as `xs:integer`, which uses `java.math.BigInteger`) with one which has a more convenient representation (such as `xs:int`, represented by an `int` primitive for a required value or a `java.lang.Integer` for an optional value). Naturally, you need to be careful when using this type of substitution that you maintain compatibility for the documents you're going to be using. The first group of child elements within the root <schema-set> element (<name-converter>, <class-decorator>, and several <schema-type> elements) configures extensions to the standard code generation. The <name-converter> element modifies name handling, in this case stripping some leading and trailing text from XML names before they're converted to Java names. The <class-decorator> element adds some useful support methods for each collection value in the generated classes, using an extension class provided as part of the JiBX distribution. You can also write and use your own code generation extensions in the same way. Finally, the <schema-type> elements change the classes and/or conversion methods used for built-in schema types. In this case the changes are to use Joda date/time classes rather than Java standard classes for date/time values, with the first customization naming specific serializer/deserializer methods and the other two just referencing predefined formats. The rest of the customizations dig down into specific schema definitions and either eliminate components which are not needed for the sample documents (by specifically including or excluding particular type definitions from a schema, or by telling CodeGen to ignore specific elements embedded within a schema definition) or specify a particular Java class name or value name to be used for a component. The ignored elements will be accepted when unmarshalling XML documents but their content will not be processed, and they will never be generated when marshalling XML documents. ### Generated code Run the 'custgen2' target and see the gen/src directory (or use the 'custom2' target to generate and compile the code, run the binding compiler, and finally run a supplied test program which roundtrips the sample documents from the samples directory). The number of generated classes is now reduced to just 15 top-level classes and 35 inner classes, or a total of 50, while still maintaining all the components needed for the sample documents. The generated class names have also been simplified by eliminating the repetitive name suffixes used in the schemas, and usage has been improved by replacing `java.math.BigDecimal` and `java.math.BigInteger` references with `java.lang.Float` and `java.lang.Integer` references, respectively. Here's a sample of the generated code (reformated for a reasonable page width, and leaving out the methods), showing the same classes as in the Example 2 generated code (with the significant differences shown in bold):
    /**
     *
     The Low Fare Search Response message contains a number of 'Priced Itinerary'
     options. Each includes:
     - A set of available flights matching the client's request.
     - Pricing information including taxes and full fare breakdown for each passenger
     type
     - Ticketing information
     - Fare Basis Codes and the information necessary to make a rules entry.
     This message contains similar information to a standard airline CRS or GDS Low
     Fare Search Response message.

     *
     * Schema fragment(s) for this class:
     * <pre>
     * &lt;xs:element xmlns:ns="http://www.opentravel.org/OTA/2003/05"
           xmlns:xs="http://www.w3.org/2001/XMLSchema" name="OTA_AirLowFareSearchRS">
     *   &lt;xs:complexType>
     *     &lt;xs:sequence>
     *       &lt;xs:choice>
     *         &lt;xs:sequence>
     *           &lt;xs:element type="ns:SuccessType" name="Success"/>
     *           &lt;xs:element type="ns:WarningsType" name="Warnings"
                     minOccurs="0">
     *             &lt;!-- Reference to inner class Warnings -->
     *           &lt;/xs:element>
     *           &lt;xs:element type="ns:PricedItinerariesType"
                     name="PricedItineraries"/>
     *         &lt;/xs:sequence>
     *         &lt;xs:element type="ns:ErrorsType" name="Errors"/>
     *       &lt;/xs:choice>
     *     &lt;/xs:sequence>
     *     &lt;xs:attributeGroup ref="ns:OTA_PayloadStdAttributes"/>
     *   &lt;/xs:complexType>
     * &lt;/xs:element>
     *
     * &lt;xs:complexType xmlns:ns="http://www.opentravel.org/OTA/2003/05"
           xmlns:xs="http://www.w3.org/2001/XMLSchema" name="SuccessType"/>
     *
     * &lt;xs:complexType xmlns:ns="http://www.opentravel.org/OTA/2003/05"
           xmlns:xs="http://www.w3.org/2001/XMLSchema" name="PricedItinerariesType">
     *   &lt;xs:sequence>
     *     &lt;xs:element name="PricedItinerary" maxOccurs="unbounded">
     *       &lt;!-- Reference to inner class PricedItinerary -->
     *     &lt;/xs:element>
     *   &lt;/xs:sequence>
     * &lt;/xs:complexType>
     *
     * &lt;xs:complexType xmlns:ns="http://www.opentravel.org/OTA/2003/05"
           xmlns:xs="http://www.w3.org/2001/XMLSchema" name="ErrorsType">
     *   &lt;xs:sequence>
     *     &lt;xs:element type="ns:ErrorType" name="Error" maxOccurs="99">
     *       &lt;!-- Reference to inner class _Error -->
     *     &lt;/xs:element>
     *   &lt;/xs:sequence>
     * &lt;/xs:complexType>
     * </pre>
     */
    public class LowFareSearchResponse
    {
        private int choiceSelect = -1;
        private static final int SUCCESS_CHOICE = 0;
        private static final int ERRORS_CHOICE = 1;
        private Warnings warnings;
        private PricedItinerary[] pricedItineraries;
        private _Error[] errors;
        private PayloadStd payloadStd;
        ...
        /**
         *  Itinerary with pricing information.
         *
         * Schema fragment(s) for this class:
         * <pre>
         * &lt;xs:element xmlns="http://www.opentravel.org/OTA/2003/05"
               xmlns:xs="http://www.w3.org/2001/XMLSchema" name="PricedItinerary"
               maxOccurs="unbounded">
         *   &lt;xs:complexType>
         *     &lt;xs:complexContent>
         *       &lt;xs:extension base="PricedItineraryType">
         *         &lt;xs:attribute type="xs:int" use="optional"
                       name="OriginDestinationRefNumber"/>
         *       &lt;/xs:extension>
         *     &lt;/xs:complexContent>
         *   &lt;/xs:complexType>
         * &lt;/xs:element>
         *
         * &lt;xs:complexType xmlns="http://www.opentravel.org/OTA/2003/05"
               xmlns:xs="http://www.w3.org/2001/XMLSchema" name="PricedItineraryType">
         *   &lt;xs:sequence>
         *     &lt;xs:element type="AirItineraryPricingInfoType"
                   name="AirItineraryPricingInfo" minOccurs="0">
         *       &lt;!-- Reference to inner class PricingInfo -->
         *     &lt;/xs:element>
         *   &lt;/xs:sequence>
         *   &lt;xs:attribute type="xs:string" use="required"
                 name="SequenceNumber"/>
         * &lt;/xs:complexType>
         * </pre>
         */
        public static class PricedItinerary
        {
            private PricingInfo pricingInfo;
            private String sequenceNumber;
            private Integer refNumber;
            ...
The differences from the generated code shown for the last example are the names used for the top-level class and some of the other classes, arrays in place of typed lists, the names of some of the fields and the simplified form of the `PricedItinerary` class (which only includes three fields rather than six, due to components eliminated by customizations), and the use of a `java.lang.Integer` in place of a `java.math.BigInteger` for the referemce number within the `PricedItinerary` class. Next: Example 4: Modular code generation