Custom boolean deserialization

[mvalero]

Hello,

I am facing the deserialization of an Edifact document into a POCO object:

The edifact messages I have to deserialize include some boolean values defined in a format that cannot directly be parsed using the boolean.TryParse method. This fields can for example include yes, no or y, n, or even its equivalent in other languages.

Currently I solved the problem creating a custom struct with a Parse method (like in your DMPeriod example) where I put my custom parsing logic.

I don't quite like this solution as I would rather have boolean fields in my model, that are directly deserialized from the edifact document.

A possible solution would be to be somehow be able to define some special converters like you can do in Json.Net. Is this supported by Edi.Net in any way? Or do you have a better suggestion on how to solve this problem?

I'm facing a similar problem with DateTime fields, as my DateTime values can come in several formats for the same field, so I cannot use the standard Format parameter of the EdiValue attribute.

Thank you in advance.

[cleftheris]

Off of the top of my head I can think of two additional ways

1. first a second property (not mapped) like the following.

        [EdiValue("X(3)", Path = "XXX/0/1")]
        public string BooleanText 
        { 
              get { return Boolean ? "yes" : "no"; } 
              set { Boolean = value == "yes"; } 
        }

        public bool Boolean { get; set; }

2. Create an enum with Yes and No or y n as possible values. This actually my be better that option 1
3. Consider custom type converters as an attribute. The ConvertUtils support it already because it is ported from JsonNet but I would have to check it out because I might not be using it :-) . This is something that will have to wait for a future release.

[mvalero]

The first option would work but I don't quite like having an extra property for each of the boolean fields in my model.

In the second point, you mean also having the extra field but of Type enum instead of string, am I right?

The custom type converters would be a much more interesting and flexible option, could you provide me with some more information on how would that fit into the current library implementation? I would be happy to contribute with a PR if you agree.