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" <[email protected]>:
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
