Conversation
… Picture struct in the implementation Renamed Picture to PictureSpec. Implemented EdifactSpec on top of IFormatSpec for support of defining the format spec in the typical format used in edifact message implementation guides Implement variable length boolean on the IFormatSpec interface and enable/disable writing padding in the ToEdiString functions of EdiExtensions Extend the EdiValueAttribute class with an enum indicating PictureSpec or EdifactSpec format
|
I am planning to work on this. I will change to a common base class. So instead of the |
|
@KoosBusters hi again. I know it has been some time since I posted to this thread. I would like to know if you are willing to help maintaining the Edi.Net project. My suggestion is primarily based on your previous contributions. Moreover, I have been overwhelmed by other obligations and the project has attracted significant attention that needs to be addressed. If you are interested let me know. |
2 participants
When implementing a protocol using an message implementation guide it is nice to follow the notation of the specs. As I understand the PICTURE notation is used for implementation guides for Tradacoms based protocols. The edifact implementation guides follow the following structures:
As I would like to create my POCO classes using the edifact notation I created an interface 'IFormatSpec' that is now implemented by PictureSpec and by the newly created EdifactSpec.
The same formatting can now be achieved in 2 notations:
[EdiValue("n3", FormatterType.EdifactSpec, Path = "DTM/0/0")]or
[EdiValue("9(3)", FormatterType.PictureSpec, Path = "DTM/0/0")]The difference is that the picture notation cannot support variable length so the Picuture class sets the VariableLength always to false in its class so the write can use the IFormatSpec interface and add padding to all EdiValues defined in the Picture notation. The EdiSpec looks for .. in the specification string and sets the VariableLength accordingly.
I'm not so happy with the fact that an enum has to be provided to the EdiValue attribute to switch between the EdifactSpec and PictureSpec but I didn't find a nicer solution for this at this moment.
The EdiValueAttribute class is an sealed attribute at this moment and I think that is for a reason, otherwise a new class could extend EdiValueAttribute and set the type enum when calling its base constructor. It is also possible to differentiate between the two notations using some regex to determine either picture or edifact notation, but it feels wasteful to use resources for this determination.
This pull requests main purpose is to collect feedback on this first attempt of an format refactor.
Releated to #23 and #43