Aufrufstatistik hat zu wenige Klicks

[achiboy]

Ich habe mir mal den Code bezüglich der Aufrufstatistik angeschaut.
Da wird in include.front_content.php abgefragt auf:

Code: Alles auswählen

    if (getSystemProperty('stats', 'tracking') != 'disabled' && cRegistry::isTrackingAllowed()) {

in der class.registry.php ist die Methode wie folgt implementiert:

Code: Alles auswählen

    public static function isTrackingAllowed()
    {
        return cSecurity::toInteger($_SERVER['HTTP_DNT'] ?? '0') === 1;
    }

Ist das nicht genau verkehrt rum? 1 bedeuted doch, dass Tracking unerwünscht ist.

[emergence]

ja, da hast du recht...

Code: Alles auswählen

    public static function isTrackingAllowed()
    {
        return cSecurity::toInteger($_SERVER['HTTP_DNT'] ?? '0') != 1;
    }

[Oldperl]

Servus achiboy,

Ist das nicht genau verkehrt rum? 1 bedeuted doch, dass Tracking unerwünscht ist.

Könntest Du dann bitte ein Ticket dazu auf Github anlegen? Danke.

https://github.com/CONTENIDO/CONTENIDO/issues

Gruß aus Franken

Ortwin

[Faar]

Mich stört am Aufbau der ganzen Sache, dass die Funktion fragt, ob Tracking erlaubt ist aber dann eine 1 = true als false umgedeutet wird.
Das liegt vermutlich daran, dass im Backend die Fragestellung zum Häckchen setzen lautet, "Tracking verbieten?" und wenn das gesetzt ist, ist es 1, also true.
Dazu passt absolut nicht die Formulierung der Funktion isTrackingAllowed() != 1, weil von der Logik der Fragestellung her müsste es == 1 sein.

So entstehen solche Fehler, wenn Funktionsnamen nicht mit der Datenerzeugung übereinstimmen.

Richtiger wäre, die Fragestellung im Backend mit "Tracking erlaubt" als positiv angehakt zu lassen, dann kommt auch eine 1 oder true für die Funktion isTrackingAllowed() in Betracht.
Man könnte auch die Funktion umgeschrieben haben "isTrackingNotAllowed() == 1" aber das wäre komplizierter...

[Oldperl]

Servus,

Richtiger wäre, die Fragestellung im Backend mit "Tracking erlaubt" als positiv angehakt zu lassen, dann kommt auch eine 1 oder true für die Funktion isTrackingAllowed() in Betracht.
Man könnte auch die Funktion umgeschrieben haben "isTrackingNotAllowed() == 1" aber das wäre komplizierter...

Äh - nein. Es ist vollkommen egal wen oder was ich in der Methode isTrackingAllowed() zur Auswertung nutze, zumal es inzwischen zur veralteten DNT-Variablen ja auch noch eine GPC-Variable gibt. Aber wie auch immer.
Es ist "unlogisch", dass sich ein Funktions-/Methodenname nach den abgefragten Bedingungen richten sollte, es ist dagegen logisch, das er die Frage, die mit seiner Benennung gestellt wurde, korrekt beantworten sollte.
Da hier die Frage ist, ist Tracking erlaubt, muss die Antwort Ja sein, wenn die DNT-Variable nicht gesetzt oder 0 ist, denn nur dann ist Tracking erlaubt.
Daher ist auch keine sinnumkehrende zusätzliche Funktion/Methode notwendig.

Gruß aus Franken

Ortwin

[Faar]

Ich sehe es trotzdem als saubere Programmierung an, wenn Funktionsbenennung und Werteübergabe und Datenabfrage übereinstimmen.
So wie jetzt muss man wissen, dass ein false postive Bedeutung hat, für die Frage, "isTrackingAllowed()". Durch das != wird es umgedeutet in true.
Das ist wie die Frage "Wenn Sie dafür sind, stimmen Sie mit nein".

Natürlich kann man es so machen, weil es möglich ist aber es ist in meinen Augen unsauber.
Man geht davon aus, true ist Zustimmung und false ist Verneinung.
Hier ist es andersrum, weil die Fragestellung im Formular andersrum ist.

[Oldperl]

Servus,

Man geht davon aus, true ist Zustimmung und false ist Verneinung.

Äh, nein - bzw. nur in Bezug auf den zurückgelieferten Wert von isTrackingAllowed().
Man geht erst mal von nichts aus was die Auswerte-Logik, also das Innere der Funktion, betrifft, zumindest ich nicht. Man schaut was der Code in der Funktion macht, welche Wertigkeit abgefragte Variable haben und ob das Ergebnis der Funktionslogik dem erwarteten Ergebnis der Funktion entspricht.
Von Außen betrachtet ist erst einmal egal, was diese interne Auswertung macht, Mich interessiert nur isTrackingAllowed == true|false
Genau das ist ja der Sinn dahinter, dass ich solche Auswertelogik in eine Funktion/Methode kapsele, ansonsten könnte ich ja auch gleich die Auswertelogik, hier die Abfrage von $_SERVER['HTTP_DNT'], im Code nutzen, und könnte mir die Funktion/Methode einfach sparen.
So aber kann ich Änderungen an der Auswertelogik und oder an der abgefragten Variablen machen, ohne das dies das Ergebnis und den Funktionsaufruf für den Anwender, bzw. für dessen Code, ändert, noch dazu nur an einer Stelle.

Daher stimme ich Deinen Ausführungen nicht zu, im Gegenteil, ich finde sie so nicht korrekt. In der Außenansicht ist das Innere der Funktion/Methode ein schwarzes Loch, und ich sehe nur die Frage, und die mögliche(n) Antwort(en). Auch darauf basiert dann beispielsweise Test-Driven Development (TDD). Die interne Umsetzung ist dem Entwickler überlassen, und die ist mir als Anwender der Funktion im ersten Moment schnurz egal.

Gruß aus Franken

Ortwin