Just had a second look,
So it seems for all the bit, bit-string, (unsigned) integer and (unsigned)
float values this would make sense ... with the string, character, date, time
and time-date fields I guess every implementation will have to come up with a
mapping, however I doubt that for these types typical range checks make sense
anyway (except string length and checking the used characters in strings).
Chris
Am 28.12.19, 09:19 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi all,
while porting the code to use the PlcValue objects I did notice when
updating all existing PlcFieldHandlers that the code looks sort of almost the
same.
While I would say the S7FieldHandler is by far the most advanced one
(actually checking the data has the right type and doing range checks for every
element).
How about moving most of this code to a base class?
I did notice that an essential part of this are the internal types defined
by every protocol. But these types might have different names, but in general
they do have the same meaning.
So how about we define an Enum with the different types and then either use
them in the drivers or simply provide a mapping of driver types to plc4x-types?
I know that writing the FieldHandler was something that required a lot of
code and coding … this way we could reuse the code and simplify things greatly
when writing new drivers?
Of course will there be fields that don’t fit this schema, especially for
KNX and BACnet, but most of the other drivers could easily reuse the code.
What do you think?
Chris
