(Imported from Google Code)
All DDMS elements that employ CombinedDateType can now support a new date format. The pattern for this format is:
May be trickier than expected.
All dates are currently handled with the XMLGregorianCalendar class, which automatically handles the 4 XML Schema date types. The default implementation of this class does not trivially support the custom ddms date type.
The date field accessors in DDMSence return an XMLGregorianCalendar, and this return type should not change (for backwards compatibility).
If the incoming date value is a ddmsateHourMinType date, it will fail to be loaded into the standard XMLGregorianCalendar implementation (com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl). I could create an extension that transforms the date by adding seconds (:00.0) to the lexicalRepresentation. This extension could be treated as an XMLGregorianCalendar, for the purposes of accessor return values, but would have some alterations:
the XML Schema DataType would be ddmsateHourMinType.
the XML Format of the return value would be the original XML value, without the added seconds.
Long-term, perhaps it makes sense to convert the return values of date accessors into XML Strings and then allow users to do what they will with the values. This remains the most true to the underlying data in the metacard at the expense of backwards compatibility.
Rev 773 refactors the existing codebase in the following ways:
XML Date caching is no longer performed on any of the date fields that will support the new DDMS date type. (This does not impact XML date caching for ISM attributes, since they only use xsd:date).
Each field that was previously Gregorian-based now has a getXxxxString() field that returns the raw XML format of the date. It is now up to the user to format as desired.
XMLGregorianCalendar-based accessors are deprecated. They will still work for the original 4 XSD date types, but will return null whenever a DDMS custom type is encountered.
This revision lays the groundwork for the real development, which now just consists of updating the Util date validation method to support the new DDMS custom type.
Complete in Rev 774.