Benachrichtigungen für 3rd Party Module

[JohnDoe]

Hallo, ich weiß leider nicht genau wie ich das beschreiben soll, deshalb auch der höchst kreative Titel

Es geht um folgendes: Ich habe eine Klasse die mehrere Dinge die ich für meine Cloud brauche bequem erledigt. Darunter zum Beispiel verschlüsseln, entschlüsseln, Dateien hochladen, Datein herunterladen, Ordner synchronisieren usw.

Linux basierte Betriebssysteme haben je nach graphischer Oberfläche ein anderes Notification-System. Ähnlich Ubuntu One (falls das jemand kennt...) will ich, nachdem zum Beispiel alles synchronisiert wurde, eine Meldung auf dem Desktop erscheinen lassen.

Mein Problem dabei: Wie mache ich das ganze möglichst einfach benutzbar und auch austauschbar? Die Basisklasse (nennen wir sie mal „Cloud“) ist vollkommen Betriebssystem- und auch Desktopunabhängig.

Wie implementiere ich sowas also am Besten? Übergeben werden sollen letztlich immer 2 Variablen, einmal der Typ („Datei verschlüsseln“, „Datei hochladen“, etc.) sowie eine Liste mit den entsprechenden Dateien. Was das jeweilige Notification-System damit macht ist mir herzlich egal, ich selbst will lediglich eine Meldung erhalten wenn alles synchronisiert wurde.

Weiß jemand wie ich sowas am geschicktesten Umsetze? Soll ich einfach eine Pseudo-Funktion in die Klasse integrieren und jeder, der Notifications haben will, muss eben die Klasse ableiten und die Funktion überschreiben oder geht das eventuell auch einfacher?

mfg

[snafu]

Funktioniert bei mir mit Python 2.x unter Cinnamon:

Code: Alles auswählen

import pynotify

def main():
    pynotify.init('Testanwendung')
    test = pynotify.Notification(
      'Test', 'Dies ist ein Test', 'dialog-information')
    test.show()

if __name__ == '__main__':
    main()

[JohnDoe]

Meine Frage war eher, wie ich eine Methode/Funktion/Whatever bereitstelle, damit man das implementieren kann. Ich bezweifle, dass Windows das Notification-System von Freedesktop.org unterstützt...

Im Moment ist es so, dass jeder Client von meiner Klasse erben muss um Notifications zu implementieren. Dazu überschreibt er einfach die Funktion notify(typ, files) und fertig.

Die Frage ist: Ist das so wie ich es mache Standard oder wird das für gewöhnlich anders realisiert?

Übertrieben gesagt will ich den Leuten eine einfache Möglichkeit geben die Aktionen, welche die Cloud im Hintergrund ausführt, sichtbar zu machen. Im Terminal brauche ich dazu ein anderes System als auf dem Desktop. Man könnte auch jede Aktion auf Twitter posten, ist in der aktuellen Implementierung auch ohne weiteres machbar. Nur der Sinn würde sich mir nicht so ganz erschließen...

mfg

[BlackJack]

@JohnDoe: Das ist eigentlich nichts was man mit Vererbung löst, weil das viel zu unflexibel ist. Man würde der `__init__()` dieser Klasse eher ein Objekt übergeben welches die Benachrichtigungen abwickelt, und je nach Plattform oder Situation übergibt man dann etwas passendes. Das Objekt kann im einfachsten Fall eine Funktion beziehungsweise etwas Aufrufbares sein.

[snafu]

Oder man macht eine zentrale Registrierungsstelle, wo sich die verschiedenen Funktionen anmelden können. Das Programm erkennt dann idealerweise automatisch, welchen Handler es aufrufen muss. Alternativ könnte man über ein entsprechendes Schlüsselwort den Handler aber auch angeben (z.B. "twitter"). Die Handler-Registrierung kann intern über ein `dict` geschehen.

[JohnDoe]

@JohnDoe: Das ist eigentlich nichts was man mit Vererbung löst, weil das viel zu unflexibel ist. Man würde der `__init__()` dieser Klasse eher ein Objekt übergeben welches die Benachrichtigungen abwickelt, und je nach Plattform oder Situation übergibt man dann etwas passendes. Das Objekt kann im einfachsten Fall eine Funktion beziehungsweise etwas Aufrufbares sein.

Danke, das wollte ich wissen. Dazu aber noch eine Frage: Infwiefern ist Vererbung in dem Falle eigentlich zu unflexibel? Ich meine es ist nicht optimal, funktioniert aber und ich sehe im Moment auch keine Nachteile.

Oder man macht eine zentrale Registrierungsstelle, wo sich die verschiedenen Funktionen anmelden können. Das Programm erkennt dann idealerweise automatisch, welchen Handler es aufrufen muss. Alternativ könnte man über ein entsprechendes Schlüsselwort den Handler aber auch angeben (z.B. "twitter"). Die Handler-Registrierung kann intern über ein `dict` geschehen.

Könnte man auch machen. Allerdings finde ich es im Moment praktischer, wenn in der __init__() einfach die Funktionen übergebe, die überschrieben werden sollen.

mfg

EDIT: Die Funktion zu übergeben funktioniert perfekt. Danke.

[BlackJack]

@JohnDoe: Du machst mit Vererbung genau diesen einen Aspekt anpassbar und verbaust Dir damit noch andere Sachen über Vererbung anpassbar zu machen. Mal angenommen das soll mit verschiedenen Clouds als Backend funktionieren, dann könnte man das ja auch per Vererbung machen. Dann hätte man eine konkrete Klasse für die Google-Cloud+Windows, Google-Cloud+Linux/Gnome, Google-Cloud+Linux/KDE, Google-Cloud+Twitter, Google-Cloud+Logfile, und Amazon-Cloud+Windows, Amazon-Cloud+Linux/Gnome, Amazon-Cloud+Linux/KDE, Amazon-Cloud+Twitter, Amazon-Cloud+Logfile. Für jede Cloud müsste man dann für jede Benachrichtigungsmöglichkeit abgeleitete Klassen erstellen. Beziehungsweise für eine neue Benachrichtigungsart, zum Beispiel Remote-Syslog, muss man für jeden Cloud-Dienst eine abgeleitete Klasse erstellen.

Was ist wenn man die gleiche Benachrichtigung gerne an mehrere Backends schicken möchte, also zum Beispiel den Benutzer über die jeweilige Desktop-Oberfläche informieren *und* in eine Protokolldatei schreiben? Muss man dann für jede dieser möglichen Kombinationen plus für jede Cloud noch mal abgeleitete Klassen erstellen? Wenn man das per Komposition statt Vererbung löst, braucht man da nur ein Benachrichtigungsobjekt, was man mit mehreren anderen als Argumenten erstellen kann, und dass dann die Benachrichtigung einfach an alle weiterleitet.

[JohnDoe]

Was ist wenn man die gleiche Benachrichtigung gerne an mehrere Backends schicken möchte, also zum Beispiel den Benutzer über die jeweilige Desktop-Oberfläche informieren *und* in eine Protokolldatei schreiben? Muss man dann für jede dieser möglichen Kombinationen plus für jede Cloud noch mal abgeleitete Klassen erstellen? Wenn man das per Komposition statt Vererbung löst, braucht man da nur ein Benachrichtigungsobjekt, was man mit mehreren anderen als Argumenten erstellen kann, und dass dann die Benachrichtigung einfach an alle weiterleitet.

Okay, das ist ein interessanter Aspekt. Daran hab ich gar nicht gedacht.

mfg