Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the EdiCondition & EdiValue attributes work together #8

Closed
cleftheris opened this issue Jul 26, 2016 · 1 comment
Closed

Make the EdiCondition & EdiValue attributes work together #8

cleftheris opened this issue Jul 26, 2016 · 1 comment

Comments

@cleftheris
Copy link
Contributor

EdiCondition attribute was originally designed in order to distinguish between different kinds of message types and deserialize accordingly. This functionality could be expanded to work with component values as well. Then someone could conditionally deserialize the same component path to different properties.

@cleftheris
Copy link
Contributor Author

cleftheris commented Aug 1, 2016

Though I managed to implement a feature while trying to achieve something like the description above, I found no easy way to support conditional values (Components) without at least a wrapper class (Element).

The reason behind this is essentialy that conditions are based upon other component values. This means that in order to know weather to deserialize and read a value one must search, deserialize and compare an other value (Component) residing on a different path. The `EdiReader advances its current position each time someone calls to Read from it so this is extremely inefficient in order to support any case because the reader would have to be able to seek back and forth for stuff.

Nevertheless, we have a nice working solution since release v1.0.8 where we enabled conditional Element classes instead! These do not compromise performance.

This enables the following scenario:

Say we got this EdiFact fragment and there is 4 DTM lines near the start. These lines may or may not be in the message and represent various date times , the first number after DTM is the field code which identifies the meaning of the line, the last line specifies the time zone - so the designer of the message unfortunately "overloaded" the meaning of DTM as is so common with legacy EDI. The challenge is that these are not really a segment in the message which would allow me to use a condition attribute to pull out the data into the relevant C# property.

But you can pull the data using a Conditional & Element class attributes with the following POCOS

    [EdiElement, EdiPath("DTM/0"), EdiCondition("137", Path = "DTM/0/0")]
    public class CreationDate
    {
        [EdiValue("9(3)", Path = "DTM/0/0")]
        public int Code { get; set; }
        [EdiValue("X(12)", Path = "DTM/0/1", Format = "yyyyMMddHHmm")]
        public DateTime Date { get; set; }
    }

    [EdiElement, EdiPath("DTM/0"), EdiCondition("ZZZ", Path = "DTM/0/0")]
    public class CreationZone
    {
        [EdiValue("X(3)", Path = "DTM/0/0")]
        public string Code { get; set; }
        [EdiValue("9(1)", Path = "DTM/0/1")]
        public int UtcOffset { get; set; }
    }

    public class Interchange
    {
        public List<Message> Messages { get; set; }
    }

    [EdiMessage]
    public class Message
    {
        public CreationDate CreationDate { get; set; }

        public CreationZone CreationZone { get; set; }
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant