Und ich als Anfänger sage:
globale Funktionen benötigen dann klar definierte vari. für Datenein- und -ausgang.
nicht mehr poc_id und zvei_id sondern id. ;)
Und ich als Anfänger sage:
globale Funktionen benötigen dann klar definierte vari. für Datenein- und -ausgang.
nicht mehr poc_id und zvei_id sondern id. ;)
naja, was ist immer gleich?
typ = POC1200, FMS, ZVEI
id = RIC, ZVEI-Code, FMS-Code
data = poc_text, ZVEI-Festtext (z.B.: Alarm), FMS-Status
sub_id = poc_sub, ZVEI-Festtext (0), FMS-Festtext (0)
time = klar oder?
Wenn wir alle Ausgaben in diese 5 vars bringen sind wir denke ich durch?
Es muss ja nicht alles dann von den Modulen genutzt werden.
Aber ausgeben seitens der Decoder-Routine sollte man alles.
Entsprechend jetzt kann dann jedes Modul schauen ob was für ihn was dabei ist und es verarbeiten.
Oder denke ich falsch?
Edit:
das gefällt mir eigentlich immer mehr. Wenn wir für den Ordner "module" quasi ein wildcard import und diese feste Datenstruktur einbauen, dann kann einfach jeder mal eben ein Modul bauen und veröffentlichen.
Und das Pflegen der Daten ist noch einfacher, ich muss für POC1200, 512, FMS, etc. alles mehrfach ändern. Bei der Modulversion reicht es einmal. Solange ich definiere, dass ich es für den jeweiligen Typ ausführen will (im Modul halt)...
Außerdem wäre das Error-Management sinniger, ich kann beim try/ex. auch direkt die Fehlermeldung generieren und weiß welcher Bereich gerade aus den Fugen springt. Sei es mySQL (okay, zeigt er jetzt auch an) oder mein firEmergency-Block oder was auch immer.
Geändert von Smith (17.05.2015 um 22:43 Uhr)
Genau da will ich hin Smith.
Es soll vorallem so laufen, das die Daten einfach rausgehauen werden. Und zwar wie du sagtest "Wildcard" an alle. Man muss also um ein neues Modul zu nutzen nix am Hauptcode ändern müssen, sondern einfach in den Module Ordner sein neues Modul reinkopieren.
Natürlich muss man wie du schon begonnen hast, eine Daten Schnittstelle fest definieren und diese dokumentieren. und schon wird es zum Kinderspiel alle möglichen Module zu nutzen.
Die boswatch.py soll im Prinzip nur die Daten annehmen. Auf Plausibilität checken, double check bzw alles was eben vorher zum filtern Sinn macht und dann einfach an die Module verteilen. Was die dann damit machen, Wayne ;-)
Nur wie man die Daten sauber an beliebig viele Module verteilt ... ?
Geändert von Schrolli (18.05.2015 um 07:49 Uhr)
Wollt Ihr wirklich den Aufwand treiben und das so generisch bauen?
In Funktionen/Module auslagern ist das eine, das ganze auch noch generisch....
Da muss man dann Helfermethoden haben...
Ich glaube bei Bedarf den if-Zweif in der Hauptdatei zu erweitern ist da einfacher.
Muss sich dann aber auf wenig Code beschränken:
Code:if useMethode: #hier evtl. sogar den get.config-Aufruf, wenn einmalig doMethode(typ, id, sub, msg)
Geändert von JHC (18.05.2015 um 08:10 Uhr)
steh ich auf dem Schlauch, oder liese sich das ganz simpelst so umsetzen?
https://lkubuntu.wordpress.com/2012/...on-plugin-api/
Und im Prinzip immer an die run() Funktion den definierten Satz an Argumenten übergeben...
Ja,klingt so...
Das Programm führt aber immer alle Plugins aus.
Eine Konfigurationsmöglichkeit müsste man noch einbauen.
Aktive Benutzer in diesem Thema: 2 (Registrierte Benutzer: 0, Gäste: 2)