KHealthCertificate in kdereview

[Volker Krause]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20210712/d48cdc01/attachment.sig>