TV-Browser-Forum

Dann ist es doch gut, dass ich das Plugin betreue und kein Außenstehender!

Während ich die besprochenen Punkte implementiert und getestet habe, ist mir noch etwas aufgefallen.
Filter im Status "Completely broken" zeigen weiterhin Filterergebnisse an.
Sollte man nicht erwarten, dass diese keine Treffer mehr anzeigen?

Wenn z. B. die CSV-Datei versehentlich gelöscht wurde, sollte der resultierende Filter eigentlich keine Daten mehr finden.
Natürlich können die, wenn das ganze zur Laufzeit passiert, noch im Hash sein und werden somit von der Komponente weiterhin an den Filter gereicht. Aber eigentlich sollte der Filterapparat solche Filter als "disabled" betrachten.

In meinem Fall habe ich jetzt in die "Completely broben"-Methode mal eingebaut, das die Daten aus dem Speicher gelöscht werden,
wenn der Rückgabewert "true" ist. Somit ist das System dann wieder konsitent.

Aber sollte das nicht die Aufgabe des Filterapparates sein? Wenn der die Nachricht bekommt, das ein Filter defekt ist,
sollte er ihn eigentlich nicht mehr ausführen. Was denkst Du?

Das ist relativ schwierig, da die Prüfung ja nur für die Anzeige des Status des Filters verwendet wird. Ruft man den Filter auf, wird das gar nicht geprüft, sondern einfach nur die accept-Methoden der beteiligten Filterkomponenten aufgerufen. Und komplett defekt muss nicht heißen, dass der Filter keine Ergebnisse mehr ausgibt, sondern kann ebenso bedeuten, dass die Ergebnisse nicht der Intention des Filters entsprechen, d.h. die Ergebnisse können falsch sein, aber auch zufällig noch richtig sein. (So ähnlich wie die Amerikaner immer sagen: "Even a broken clock ist right twice a day.")

Die Filterkomponente hat ja immer noch die Möglichkeit selbst zu wissen, dass sie komplett defekt ist und dann gibt sie einfach immer false zurück, so dass es zu keinem Zeitpunkt noch ein sichtbares Ergebnis gibt.

Bei mir ist es ja verhältnismäßig eindeutig, da ich den Status "completely broken" mit dem Zustand der CSV-Datei in Verbindung bringe.

Deine Beispiele hätte ich jetzt eher mit dem Status "partially broken" in Verbindung gebracht.
Mit dem Status "completely broken" assoziiere ich "Nichts geht mehr!".
Natürlich ist das immer eine Frage der Sichtweise.

Könnte man nicht vor dem Aufruf der accept-Methode zuerst die "completely broken" - Methode aufrufen und dann entscheiden?

Sicher könnte man das, erhöht aber den Aufwand unnötig. TV-Browser zeigt an, dass die beteiligten Filterkomponenten alle der Meinung sind, dass sie komplett defekt sind, indem der Filter durchgestrichen und rot markiert wird. Die Filterung selbst wird unabhängig davon so wie immer aufgerufen, was sehr viel simpler ist, da keine Fallunterscheidungen nötig sind. Die Filterkomponente wissen selber ob sie defekt sind und wie darauf zu reagieren ist.

Ich finde es halt immer schwierig, wenn ein System inkonsistente Informationen liefert.
Dann werde ich es so, wie implementiert, lassen, und im Fall einer CSV-Datei Filterkomponente im Status "completely broken" die Daten aus dem Speicher löschen. Dann ist diesbezüglich alles sauber.

Oder ich merke mir den Rückgabewert in einem Klassenfeld und gebe dann immer false zurück, wenn sie "completely broken" ist.
Ist vielleicht charmanter

Ja, das erscheint mir sinnvoll, denn dein Argument könnte man auch einfach umdrehen. Wenn die Filterkomponente anzeigt komplett defekt zu sein, aber immer noch Sendungen mit true filtert, ist sie nicht wirklich komplett defekt.

Eine Kleinigkeit habe ich noch gefunden. Das fällt insbesondere bei der CSV-Datei-Filterkomponente auf.

Wenn ich im TV-Browser einen Filter ausgewählt habe, der eine CSV-Datei-Filterkomponente enthält und dann die CSV-Datei lösche,
dann wird der Filter als "completeley broken" rot markiert. Aber die Daten werden in diesem Moment immer noch angezeigt.

Mit meiner Implementierung werden beim nächsten Aufruf des Filters die Daten nicht mehr angezeigt. So solle es auch sein.

Mir geht es jetzt um die obige Situation. Ich fände es gut, wenn der Filter aktualisiert würde, wenn sich der Status ändert.
Dann würde im oben beschriebene Fall meine Implementierung direkt greifen und die Daten würden nicht mehr angezeigt.
Umgekehrt würden die Daten wieder erscheinen, wenn ich die Datei wiederherstelle.

Warum ist dir das so wichtig? Es reicht doch, wenn TV-Browser anzeigt, dass etwas nicht stimmt. Die Anzeige und die Filterung sind aber voneinander komplett unabhängig. Das eine hat mit dem anderen wenig zu tun. TV-Browser würde die Filterung nur dann aktualisieren, wenn der Filter neu ausgewählt wird. Das könnte das Plugin theoretisch erreichen durch Aufruf von: Außerdem sollte sich die Anzeige als defekt auch weniger zur Laufzeit ändern, nur wenn man etwas an den Filtern ändert oder die Sender oder Plugins aktualisiert werden, wird die überhaupt aktualisiert. Also gibt es sowieso keine Sicherheit, dass die Information zu jeden Zeitpunkt korrekt ist. Die Idee ist ja auch, dass es irgendwann auffällt, nicht zwangsläufig sofort.

Ich zitiere:

ds10 hat geschrieben:Wenn die Filterkomponente anzeigt komplett defekt zu sein, aber immer noch Sendungen mit true filtert, ist sie nicht wirklich komplett defekt.

Aber natürlich ist der angeführte Fall eine extreme Ausnahme, die wahrscheinlich nie auftritt.

Die einzige Möglichkeit das zu ändern, wäre dass der Filter an TV-Browser melden kann, wenn er defekt ist. Aber das halte ich dann doch für übertrieben. Sollte es Filter defekt sein, wird man das spätestens, nach einem Neustart sehen.

Das wäre theoretisch die korrekte Methode, aber wohl zu aufwendig.

@Anderella:

Ich habe eine neue Version der CSV-Datei-Filterkomponente bereitgestellt.
Nach dem Update kannst Du das führende Semikolon aus dem Eintrag

;Raumschiff Enterprise;Das letzte seiner Art;1;1;;;

wieder entfernen. Der Fehler sollte nun nicht mehr auftreten.

Hallo.

Hab's grad installiert & probiert, funkt wieder bestens !!!

Tausend Dank

Hallo,

könnte bitte jemand verifizieren, ob es ein "neues" Problem gibt

Meine Filter Komponente findet zwar alle Einträge für Walking Dead, bis Episode 11, die kommenden (12-16) nicht.
Danke.