Hi all, just in time for going to that free music festival in Darmstadt I finally finished the serialization code generation. I know there's still one or two issues with "optionalField"s but I think in general you should get the idea.
If you want to try it out, please checkout the "feature/code-gen" branch and update that. In the "sandbox/code-generation" directory is a maven project that's separate from the rest. You should be able to build it with: "mvn clean package" ... then in the "test-java-s7-driver/target/generated-sources/plc4x" directory, you should see the generated code. It doesn't do anything yet as I haven't implemented the ReadBuffer and WriteBuffer methods, so please just have a look at the code ... I'll fill the rest with life next weekend (or during the weekend as I do know that I just can't resist working on this ;-)) Chris Am 30.05.19, 11:04 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, I think you misunderstood my question /problem. The s7 protocol already is layered with 3 layers. The problem I am currently having is more a problem if how to write the parser software. In case of the s7 message there are slightly different header fields, depending on the type, but the payload is the same. Ideally I would have parsed the data of the base type first and passed that to the sub-type, which then does the intantiation. Here however parameter and payload are still missing, because they haven't been parsed yet and can only be parsed after the sub-type is done parsing its parts. Now I could make these properties mutable and set them using setters after the type is instantiated (which isn't nice)... Or I have the subtype parser return an object containing only the subtype fields and a builder method, which takes all the base-type fields and is called at the end of the base type parser. It then uses all the fields of the base-type which are passed as argument to the builder method plus the sub-type fields it contains and is then able to construct an immutable Object. Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Julian Feinauer <[email protected]> Sent: Thursday, May 30, 2019 12:06:22 AM To: [email protected] Subject: Re: [DriverGen] Major refactoring and great improvements 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" <[email protected]>: 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
