Allow mappers to configure Tag properties

[timyhac]

Mappers have historically been used to map between CLR objects and the byte array returned by libplctag core. Since this was introduced, a number of features have been developed that allow significantly more configuration/customization of what the core library does (e.g. string parameters, byte orders, raw CİP).

Provide a way for the mappers to configure some or all of this information.

İmplementation note: provide a function that acts on the Tag, just prior to Tag initialization.

[jkoplo]

I looked through the PR on this (#212) and it doesn't fully make sense to me. I saw the example in there, but maybe I need a better use-case?

The Mappers have a pretty clearly defined concern - take raw data and turn it into a CLR type. This kind of feels like it's breaking that and giving Mappers a way to change the request data? Not saying the feature isn't needed, more that maybe we implement it a different way.

[timyhac]

I agree that "Mapper" would be the wrong word to use if it can also configure Tag properties. With respect to use-cases, it would allow configuration of all of the new parameters that the core library supports (string parameters, byte orders, etc) that are used to define how the tag works.

The extra functionality provided by the string properties used to be in the Encode/Decode method on the StringPlcMapper class (less comprehensively as the core library does it). Now, there is no way to access this functionality - we'd either need to provide an opportunity for the Mapper to do it (i.e. before the tag is initialized), or expose it on the TagOfT class and ask the user to configure those properties.

[timyhac]

I guess the other option could be to reassess the TagOfT class + Mapper architecture - it could be abstract+concrete classes. I'll explore what this looks like to see if its worth pursuing.

[jkoplo]

I think we need to expose the new configuration properties but I think maybe it should be done a different way. Some ideas:

• Inherit TagOfT when needed and override/add functionality
• Set some extra (optional) config into TagOfT either as a delegate or as a ProtocolConfig class (terrible name, but you get the idea)
• Break TagOfT up into different pieces/refactor it

[jfontsaballs]

I believe it is a good idea that mappers are able to configure attributes on tags, as many attributes are related to the behavior of the native library's functions that transform the bits and bytes received from the PLC to meaningful values, and which mappers make use of.

[timyhac]

@jkoplo FYI I removed this from the 1.2.0 plan because it's a breaking change and would require a major version increment.

[timyhac]

Two more examples where having hooks to call code around Initialize would be useful:

• Dynamic tags - after calling Initialize(..) or one if its variants, determine the type of the PLC data using GetByteArrayAttribute or some other method, and subsequently configure the appropriate Encode/Decode routines. Note that this requires a hook after calling Initialize, whereas the other use cases require calling it before. See example.
• Using the tag name to configure the appropriate Encode/Decode routines. Some devices have a tag buffer response that changes depending on the tag name provided despite encoding the same data (Bool arrays on Omron, see this issue)

This isn't exactly what I had in mind when creating this issue 3 years ago (it was more to provide ability to configure underlying tag before Initialize) but is related.