Hi all,

In the train (Which I didn't miss) I had an idea.

I'd like to add a "virtual" field which generates a get-method without any 
property to back it in the pojo.
This can be helpful when working with the model objects.

It could look something like this:
        [virtual uint 8 'hurz' 'field1.size + field2.size - 5']

Which generates this in the pojo:

        public short getHurz() {
                return (short) (getField1().getSize() + getField2().getSize() 

For the other case we have a normal field, but want to externally or manually 
map the content form and to the field.
So how about "externalField" or "manualField" and "externalArrayField" or 
"manualArrayField" for single or multi-value fields.

For these fields I would suggest to give them two expressions: One 
parsingExpression and one serializationExpression ... the pojo part would be 
identical to the normal field and arrayFields.


Am 07.08.19, 18:14 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

    Hi Julian,
    As all of the elements are "fields" I thought it as a virtual field... 
That's why I suggested that. If you go for "external" it would be an external 
field, which is sort of not quite what it is. And the "whatever name it has" - 
field doesn't have to call external code... It could just be an expression 
which is evaluated... Just in the pojo instead of the io component.
    But I'm not insisting on "virtual" ;-)
    Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
    From: Julian Feinauer <j.feina...@pragmaticminds.de>
    Sent: Wednesday, August 7, 2019 11:49:45 AM
    To: dev@plc4x.apache.org <dev@plc4x.apache.org>
    Subject: Re: [CODE GEN] Extending the mspec to support arrays terminated by 
conditions instead of just "length" and "count", and others ...
    Hi Chris,
    first, thanks for the update here.
    I already checked your results this morning with Volker and have to say 
THANK both of you for your effort, we are pretty close on closing this off : )
    For the rest... I agree with your suggestions. Perhaps instead of 'virtual' 
we could use 'external', as we call external code.
    It would be good for us to also generate Interfaces for those externals as 
this would make it easier to add everything in another language, if we generate 
the "skeleton" like that.
    Am 07.08.19, 11:04 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
        Hi all,
        yesterday Volker and I meet in our codecentric office in FFM and worked 
on a DF1 driver based on mspec and generated code.
        Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
        For the DF1 protocol we also need to be able to continue adding 
elements until a termination condition is true (In this case reading the 0x10 
0x03 byte sequence). So I’ll be extending the spec format with this feature. I 
would suggest not to use some sort of termination characters, but to call a 
function which tells the array to read another element or not.
        Also did we encounter a situation where byte data is escaped … so in 
this case if the data contains the byte 0x10, this has to be escaped by 
duplicating it to 0x10, 0x10. This makes things a little tricky as we have to 
ignore the second 0x10 for the termination condition.
        Last thing we noticed: for calculating the CRC checksum, it would be 
good to have a new type of field in the spec. One that isn’t used for parsing 
or serializing, but for referencing it (in expressions for example) … Not sure 
how to call it tough … was thinking of “virtual”

Reply via email to