You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: