castor

Refactor org.exolab.castor.builder.types package

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.1 M2
  • Fix Version/s: 1.1 M3
  • Component/s: XML code generator
  • Labels:
    None
  • Number of attachments :
    1

Description

That package contains a lot of duplicated code and its class hierarchy needs masiv changes.

Please do not commit any change to classes of this package as there is no way to merge them with my patch.

Issue Links

Activity

Hide
Ralf Joachim added a comment -

I finished almost all code formating work and refactoring of class hierarchy. Still improvment of setFacets() and validationCode() methods are missing. Having said that I recoginized and fixed a valueable number of small issues at the refactored classes.

I also need to mentioned that still some XML schema types are not supported. The missing ones are:

  • token
  • Name
  • language
  • ENTITY
  • ENTITIES
  • NOTATION

After this task has been finished I think we should also separate IDREFS and NMTOKENS from our global COLLECTION type (XSList) to omit looking into the collections component type at various areas.

Show
Ralf Joachim added a comment - I finished almost all code formating work and refactoring of class hierarchy. Still improvment of setFacets() and validationCode() methods are missing. Having said that I recoginized and fixed a valueable number of small issues at the refactored classes. I also need to mentioned that still some XML schema types are not supported. The missing ones are:
  • token
  • Name
  • language
  • ENTITY
  • ENTITIES
  • NOTATION
After this task has been finished I think we should also separate IDREFS and NMTOKENS from our global COLLECTION type (XSList) to omit looking into the collections component type at various areas.
Hide
Ralf Joachim added a comment -

It need to be noted that I changed one contract during refactoring, values like maxExclusive or fixed are not validated during source generation as their value range should be valid if the xsd is valid.

In addition to the observation of none supported types there are still 4 supported types that do not support all factes or no facets at all.

  • base64Binary
  • heyBinary
  • dateTime (as already mentioned by eddie)
  • IDREF

All other types now support all facets which they didn't do before the refactoring.

Show
Ralf Joachim added a comment - It need to be noted that I changed one contract during refactoring, values like maxExclusive or fixed are not validated during source generation as their value range should be valid if the xsd is valid. In addition to the observation of none supported types there are still 4 supported types that do not support all factes or no facets at all.
  • base64Binary
  • heyBinary
  • dateTime (as already mentioned by eddie)
  • IDREF
All other types now support all facets which they didn't do before the refactoring.
Hide
Ralf Joachim added a comment -

Another bug that I fixed was at xsd:integer, xsd:positiveInteger, xsd:negaitiveInteger, xsd:nonPositiveInteger and xsd:nonNegativeInteger. While they used Long class we called Long.intValue() instead of Long.longValue() at conversion to a primitive value.

Show
Ralf Joachim added a comment - Another bug that I fixed was at xsd:integer, xsd:positiveInteger, xsd:negaitiveInteger, xsd:nonPositiveInteger and xsd:nonNegativeInteger. While they used Long class we called Long.intValue() instead of Long.longValue() at conversion to a primitive value.
Hide
Ralf Joachim added a comment -

Final patch.

Show
Ralf Joachim added a comment - Final patch.
Hide
Ralf Joachim added a comment -

At the list of types where facet support are missing and no validation code gets generated i missed xsd:anyURI.

Show
Ralf Joachim added a comment - At the list of types where facet support are missing and no validation code gets generated i missed xsd:anyURI.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: