Verletzung der Plugin-Schnittstelle

Forumsregeln

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
BBCode ist eingeschaltet
[img] ist eingeschaltet
[url] ist eingeschaltet
Smileys sind ausgeschaltet
Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Ansicht erweitern Die letzten Beiträge des Themas: Verletzung der Plugin-Schnittstelle

von pck » 13 Feb 2005, 19:39

Til hat geschrieben:Beim Lieblingssendungenplugin ist die wichtigste Aktion zweifelsohne "Zu Lieblingssendungen hinzufügen". Die macht halt bei einer Sendung, die bereits Lieblingssendung ist keinen Sinn.
Wenn es in TVB1.1 eine saubere Schnittstelle gäbe die "Aktionen ohne Programm" zurückliefert dann könnte der Benutzer hier einfach "Lieblingssendung hinzufügen/entfernen" auswählen. Das wäre sogar eleganter als der Ist-Zustand bei TVB1.0.1.

Ohne eine Schnittstelle kann der Benutzer bei mir nur "Aktion 1 / FavoritePluginId" auswählen und ich kann vielleicht "'BeispielTitel" zu Lieblingssendungen hinzufügen" als Hinweis auf die eigentliche Funktion anzeigen. Das ist natürlich Suboptimal, aber bevor wir hier noch länger diskutieren ...

von Til » 13 Feb 2005, 19:35

pck hat geschrieben:Und ... verstehe ich richtig, das du es für einen Bug in 1.1cvs hältst, dass man unter Aussehen->Kontextmenü->SelektiertesPluginMitDoppelklickAusführen auch das FavoritesPlugin auswählen darf?
Mann, mann. Also entschuldige, wenn ich das mal so sage, aber du bist in manchen Dingen ganz schön kleinkariert...

Nein, es ist kein BUG. Es gibt im PluginManager eine Methode "getExampleProgram", die das Program zurückgibt, die von dieser Auswahl genutzt wird, um die Aktionen zu bestimmen. Ein Plugin kann damit dann "typische" Aktionen zurückgeben. Klar kann es dann passieren, dass die gewählte Defaultaktion nicht auf jedes Program anwendbar ist. Dann passiert halt nichts bei nem Doppelklick.

von Til » 13 Feb 2005, 19:27

pck hat geschrieben:
Til hat geschrieben:Bei deiner Variante gehst du davon aus, dass jede Aktion mit jedem Program ausführbar ist.
Klingt "die wichtigsten Pluginaktionen" für dich nach "jede Aktion"?
Von mir aus gehst du halt davon aus, dass "die wichtigste Pluginaktion" mit jedem Program ausführbar ist. Leider ist auch das mit dem neuen Ansatz nicht gegeben.

Beim Lieblingssendungenplugin ist die wichtigste Aktion zweifelsohne "Zu Lieblingssendungen hinzufügen". Die macht halt bei einer Sendung, die bereits Lieblingssendung ist keinen Sinn.

von pck » 13 Feb 2005, 19:22

Naja ... brauchst nicht zu antworten. Du hast richtig verstanden was ich vorhabe und wenn ihr hier keine offizielle saubere Schnittstelle wollt finde ich das schade aber es ist kein Beinbruch.

von pck » 13 Feb 2005, 19:06

Til hat geschrieben:Das Lieblingssendungen-Plugin kann bei einer Sendung, die noch keine Lieblingssendung ist die Aktion "Zu Lieblingssendungen hinzufügen" anbieten. Bei einer Sendung, die bereits Lieblingssendung ist, kann die Aktion "Aus Lieblingssendungen entfernen" angeboten werden. Um so etwas zu ermöglichen, muss also eine Aktion an ein Program gebunden sein.
Und ... verstehe ich richtig, das du es für einen Bug in 1.1cvs hältst, dass man unter Aussehen->Kontextmenü->SelektiertesPluginMitDoppelklickAusführen auch das FavoritesPlugin auswählen darf?

von pck » 13 Feb 2005, 18:50

Til hat geschrieben:Bei deiner Variante gehst du davon aus, dass jede Aktion mit jedem Program ausführbar ist.
Klingt "die wichtigsten Pluginaktionen" für dich nach "jede Aktion"?

von Til » 13 Feb 2005, 18:42

Wir haben die Methode getContextMenuActions(Program) mit Absicht so entworfen, dass die Aktionen vom Program abhängen.

Damit ist es möglich, je nach Program zu entscheiden, welche Aktionen möglich sind. Beispiel: Das Lieblingssendungen-Plugin kann bei einer Sendung, die noch keine Lieblingssendung ist die Aktion "Zu Lieblingssendungen hinzufügen" anbieten. Bei einer Sendung, die bereits Lieblingssendung ist, kann die Aktion "Aus Lieblingssendungen entfernen" angeboten werden. Um so etwas zu ermöglichen, muss also eine Aktion an ein Program gebunden sein.

Bei deiner Variante gehst du davon aus, dass jede Aktion mit jedem Program ausführbar ist.

von pck » 13 Feb 2005, 18:13

Til hat geschrieben:@pck: Die Sache mit den "gebundenen" und "ungebundenen" Methoden kapier jetzt nicht so ganz. Erklär's doch bitte nochmal für Dumme... :wink:
Ich hatte gehofft mein Wunsch nach eigenen "Defaultaktionen" wäre verständlich wenn man mein Plugin mal angeschaut hat, selbst wenn man die Begriffe aus dem Lambda-Kalkül nicht kennt. Sorry. Meine Formulierung "gebundene Methoden" ist zudem schwammig. Korrekt wäre "Funktionen ohne freie Variablen". Ich erklär's mal an einem Beispiel:

Code: Alles auswählen

Plugin plugin = new ListViewPlugin();
Action action = manager.getActivatedPlugins()[0].getContextMenuActions(program).getAction();
PluginManager manager = getPluginManager();

plugin.execute(program); // A
action.actionPerformed(); // B
manager.handleProgramDoubleClick(program); // C
Die Zeilen A, B und C machen in etwa dasselbe. Alle führen die Funktion "Plugin.execute(Program)" aus. (Stimmt nicht ganz, aber tun wir mal so als ob.) Die Funktion hat zwei Variablen, ein Plugin namens "this" und eine Sendung namens "program".

In Zeile "A" kann man "this" (=plugin) und "program" angeben. Man spricht von "freien Variablen".

In Zeile "B" hat man keinen Einfluss darauf, welches Plugin welches Programm bearbeitet. Die Variablen "this" und "program" sind "gebundene Variablen".

In Zeile "C" ist "this" eine "gebundene Variable" und "program" eine "freie Variable".


Mit TVB1.0.1 kann ich alle Plugins wie in Zeile "A" aufrufen. Das wird in TVB1.1 nicht gehen und das ist sicher auch gut so.

In TVB1.1 kann man alle Plugins wie in Zeile "B" aufrufen. Das ist meist ok, aber der Benutzer muss bei jedem Aufruf erneut auswählen was er tun will.

Ich würde in TVB1.1 gerne die wichtigsten Pluginaktionen wie in Zeile "C" aufrufen können. Wenn der Benutzer eine Funktion häufig aufrufen will, dann braucht er nicht jedesmal ein Kontextmenü zu nutzen.

von Martin » 13 Feb 2005, 14:37

Til hat geschrieben:Aber es ist doch besser, dafür eine eigene Klasse zu spendieren, oder sollte das ganze in den devplugin.PluginManager?
ja, eine eigene Klasse mit den Settings. Aber im PluginManager eine Methode getSettings()...

von Til » 13 Feb 2005, 14:14

@pck: Die Sache mit den "gebundenen" und "ungebundenen" Methoden kapier jetzt nicht so ganz. Erklär's doch bitte nochmal für Dumme... :wink:

von Til » 13 Feb 2005, 14:13

pumpkin hat geschrieben:Und eine Liste der im Moment sichtbaren Sendungen (damit man für Markierungen wie sie z.B. NewsFeed macht nicht alles durchsuchen sondern nur einen Tag durchgehen muss)
Im PluginManager gibt es doch "getSubscribedChannels()" und "getChannelDayProgram(Date, Channel)".

Wenn du jetzt noch den aktuellen Tag bekommst, dann hast du doch alles, was du brauchst, oder?
pumpkin hat geschrieben:Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.
Das geht doch auch schon...

Die Plugin-Schnittstelle ist jetzt schon recht umfangreich. Ich würde das ungerne mit "praktischen" Hilfsmethoden überfrachten. Es könnte sonst leicht passieren, dass neue Plugin-Entwickler von zu vielen Methoden überfordert werden...

von bodo » 13 Feb 2005, 14:09

Eigene Klasse macht mehr Sinn. Und vergesst die Zeit-Knöpfe nicht, die brauch ich im ListView-Plugin ;)

von Til » 13 Feb 2005, 14:08

Martin hat geschrieben:
Til hat geschrieben:Dann lieber eine extra Klasse für die Plugins über die ausgewählte Einstellungen lesend genutzt werden können. Dort könnte man dann Getter-Methoden anbieten und gegebenenfalls deprecated machen...
ja, find ich ok so. Da müssen dann aber nicht alle Einstellungen angeboten werden, sondern nur jene, die ein Plugin evtl. brauchen kann.

Gut wäre auch ein Getter für das TV-Browser-Home-Verzeichnis
Aber es ist doch besser, dafür eine eigene Klasse zu spendieren, oder sollte das ganze in den devplugin.PluginManager?

von pck » 13 Feb 2005, 13:49

Til hat geschrieben:
pck hat geschrieben:Und ein Ersatzmechanismus, das Zugriff auf "ungebundene" Methoden anderer Plugins erlaubt ist noch nicht vorhanden. Und selbst wenn er vorhanden wäre könnte ich kein versionsunabhängiges Plugin schreiben, da Reflection hier nur eingeschränkt erlaubt ist.
Wie gesagt: Es hat niemand mehr direkten Zugriff auf Plugins. Das heißt, dass es technisch einfach nicht geht (außer mit einer Hintertür). Deshalb kann man leider kein versionsunabhängiges Plugin schreiben, das auf andere Plugins zugreift.
Lasst uns erstmal zwei Probleme auseinanderhalten:

A) Versionsunabhängigkeit ist nicht gut machbar weil Plugins keine Aufrufe über die Reflection-API machen dürfen während die TVBrowser-APIs nicht abwärtskompatibel sind.

B) In TVBrowser 1.0.1 konnte man über Plugins an ungebundene "Aktionen" für Programme kommen. In TVBrowser 1.1cvs kann man über PluginAccess nur an gebundene "Aktionen" kommen. Es ist ok, dass ihr direkten Zugriff auf Plugins verhindert. Ich finde es aber schade, dass es beim PluginAccess keine ZUSÄTZLICHE Schnittstelle gibt, bei der ich "Aktionen" erhalte, die erst beim Aufruf an eine konkrete Sendung gebunden werden.

Code: Alles auswählen

interface devplugin.UnboundProgramAction {
  String getId();
  String getName();    // oder "Action getPlaceholderAction()"
  Action bindAction(devplugin.Program prog); // may return null
}
Das ist technisch kein Problem und der Anwender könnte auch weiterhin kontextabhängige Defaultaktionen auswählen.

von pumpkin » 13 Feb 2005, 13:31

Und eine Liste der im Moment sichtbaren Sendungen (damit man für Markierungen wie sie z.B. NewsFeed macht nicht alles durchsuchen sondern nur einen Tag durchgehen muss)

Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.

Nach oben