1

Resolved

Bug: DateTimeField Import/Export node mismatch

description

The DateTimeFieldDriver exports the value as an attribute named "DateTime", but it imports a value from an attribute named "Value":

Importing:
context.ImportAttribute(GetPrefix(field, part), "Value", v => field.Storage.Set(null, XmlConvert.ToDateTime(v, XmlDateTimeSerializationMode.Utc)));
Exporting:
context.Element(GetPrefix(field, part)).SetAttributeValue("DateTime", XmlConvert.ToString(field.Storage.Get<DateTime>(null), XmlDateTimeSerializationMode.Utc));
It should either both be "Value" or "DateTime".

comments

agriffard wrote Mar 28, 2013 at 3:55 PM

As the property name in DateTimeField is DateTime, it should be DateTime in importing :
    protected override void Importing(ContentPart part, Fields.DateTimeField field, ImportContentContext context) {
        context.ImportAttribute(GetPrefix(field, part), "DateTime", v => field.Storage.Set(null, XmlConvert.ToDateTime(v, XmlDateTimeSerializationMode.Utc)));
    }

sfmskywalker wrote Mar 30, 2013 at 11:46 PM

Fixed in changeset 7b90d59c65b2

CSADNT wrote Mar 31, 2013 at 9:28 AM

Wouldn't have been better to keep Datetime rather than Value which is a kind of reserved word in xml ?

sfmskywalker wrote Mar 31, 2013 at 5:27 PM

I see your point, but we chose to maintain the import feature working for those cases where users might already depend on the working Import feature.

CSADNT wrote Mar 31, 2013 at 9:44 PM

Usually we do this implementing a versioning.
I have not been looking in import detail, but if tehre is no root class implementing versioning, it's worth adding it, it's easy with an xml node.
For previeous versions compatibility the existence of of the version node should be tested.
We have not to propagate through time bad choices.
If there is no 'root' versioning in import/export it's easy to implement it locally.

sfmskywalker wrote Mar 28 at 12:28 AM

Fixed in changeset 44b7ba4c7a84f7cdc719bc8bfa5cc3f527c1822f