Hey Chris,
this is one oft he problems I also stumbled across when reasoning and which I
consider 'hard'.
One way to make it way cleaner would be to switch to a layered architecture.
If we generally distinguish between Transport Layers and Communication Layer
(better anmes are welcome) we can introduce a general format of these transport
layers which is
[Type
[Some Type of header Stuff]
[byte[] payload]
[Some Type of fooder Stuff]
]
This would also enforce reusability.
Or am I getting things wrong?
Am 29.05.19, 23:55 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi all,
so today I somewhat finished the POJO generation for Java and am currently
implementing the IO classes to parse the POJOs (Second step will be serializing)
Now I stumbled into following problem (One example from the S7 protocol):
[discriminatedType 'S7Message' ['payloadLength']
[const uint 8 'protocolId' '0x32']
[discriminator uint 8 'messageType']
[reserved uint 16 '0x0000']
[field uint 16 'tpduReference']
[implicit uint 16 'parameterLength' 'parameters.size']
[implicit uint 16 'payloadLength' 'payloads.size']
[typeSwitch 'messageType'
['0x01' Request
[context string 'messageType' 'request']
]
['0x03' Response
[context string 'messageType' 'response']
[field uint 8 'errorClass']
[field uint 8 'errorCode']
]
['0x07' UserData
[context string 'messageType' 'userData']
]
]
[field S7Parameter 'parameter' {messageType: 'messageType'}]
[field S7Payload 'payload' {messageType: 'messageType', parameter:
'parameter'}]
]
As you can see there's properties that belong to the base type and parts
that belong to Request, Response and UserData ... however this information is
sort of in-between the header and the footer.
Enforcing the switch to be the last and pulling the parameter and payload
into the cases, sounds like an ugly restriction.
So I thought that I might generate some parser classes for the sub-types,
that contain the sub-type properties only and a factory method ... to in this
case the Response factory pojo class which would sort of look like this:
public class ResponseDelayedBuilder implements DelayedBuilder {
private final short errorClass;
private final short errorCode;
public ResponseParserModel(short errorClass, short errorCode)
{
this.errorClass = errorClass;
this.errorCode = errorCode;
}
@override
public Response build(int tpduReference, S7Parameter parameter,
S7Payload payload) {
return new Response(tpduReference, parameter, payload,
errorClass, errorCode);
}
}
Is there a cleaner way of doing something like this?
Chris
Am 29.05.19, 09:34 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi all,
I just wanted to give you all an update on how we are progressing on
the driver generation front.
I just pushed some major refactorings which transition the POC more in
the direction of something usable.
Here the most important changes:
* There are Protocol-modules which are discovered similar to how we
discover drivers in the classpath
* There are now Language-(output)-modules which also are discovered
similar to how we discover drivers in the classpath
* The input modules generally provide only the spec
* The output modules contain everything needed to produce output
for a given language
* In order to allow experimentation of the output variants the
output modules contain everything needed to generate the output
* My implementation of a language-template-java uses freemarker to
generate output, but others could simply use other techniques
So far I have a pojo template that will generate the POJO classes for
the types in the spec.
Right now I’m working on the little tool that will tell the output
which Java type it should use for which spec type …
but as soon as that’s done I’m looking forward to implementing the IO
components.
All of this is happening in the “feature/code-gen” branch … and all my
code-generation related code is in sandbox/code-generation
So far the update …
Chris
