On Montag, 12. Juli 2021 13:36:11 CEST Harald Sitter wrote: > My only gripe, besides what Albert already pointed out, is that all > the properties are WRITEable but have no NOTIFY signal nor are they > CONSTANT. One of those things ought to change. Considering only the > certificate objects have properties and they are always constructed by > the parsers I guess you could just drop the WRITE and make them > CONSTANT?
CONSTANT vs NOTIFY is a bit pointless on Q_GADGETs as NOTIFY isn't possible
there at all, but WRITE is indeed neither needed nor desired here. Fixed.
> There is a somewhat different approach, that I only bring up because I
> do enjoy meta programming way too much: Currently the parsers have
> exhaustive if-else constructs to map incoming fields to setters. What
> you could do is make static maps from incoming keys to property key
> and then write the property filing in an abstract fashion e.g. to
>
> illustrate:
> > static QMap<QString, QString> propertyMap{{"tg", "disease"}, {"fr",
> > "dateOfPositiveTest"}, ...}; while (reader.hasNext()) {
> > cert.setProperty(propertyMap.value(key), CborUtils::readString(reader));
> > // needs some error handling when key mapping fails and possibly type
> > conversion helpers }
>
> Then the WRITE would make sense and I'd use a single "changed()"
> signal to NOTIFY on all the properties. drkonqi's bugzilla library
> does something like that to model API objects for example.
Good idea in general, however tricky to apply here I think as the amount of
different types or ways of parsing the raw data is not significantly less than
the amount of properties, so I don't expect much to be gained by this.
Thanks!
Volker
signature.asc
Description: This is a digitally signed message part.
