wiki:IPlugin Requirements

Auf dieser Seite wird die Spezifikation einer neuen IPlugin-Schnittstelle erarbeitet.

Qualitative Anforderungen

  • Was IPlugin-Entwickler erwarten:
    • schlanke, einfach zu implementierende Schnittstelle
    • Entlastung des Plugins von sämtlichen Funktionen, die nicht zur unmittelbaren Plugin-Funktionalität gehören
    • keine Codeblöcke, die sich in mehreren Plugins wiederholen
    • klar definierte und intuitive Funktion aller Bestandteile der Schnittstelle (jede Funktion sollte frei von Seiteneffekten sein und nicht zum Missbrauch zur Umsetzung einer anderen Funktion verleiten)
  • Was sich aus den Anforderungen an die visuelle Programmiersprache sowie der Ausführungsmaschine ableitet:
    • schnelle Übergabe von Ein- und Ausgabeparametern
    • Unterstützung beliebiger Datentypen
    • saubere Trennung von Ausführung und Visualisierung

Funktionale Anforderungen

  • Ausgabeparameter sollten nur dann aufbereitet/geliefert werden, wenn sie benötigt werden. Beispiel: ICryptoolStream und byte[] als Ausgabeparameter. Wenn nur der Streamausgang verbunden ist, braucht man kein byte[] erstellen. (demand-driven)
  • Auf Eingabeparametern sollte keine Verarbeitung nötig sein, z.B. sollte der Plugin-Entwickler nicht OnPropertyChanged für das QuickWatch-Update auf Eingabeparametern ausführen müssen, da es Editor/Ausführungsmaschine unter sich mitteilen können ohne den Umweg über das Plugin.
    • Denkbar: Man könnte vom Plugin-Programmierer erwarten, dass er Eingabeparameter händisch konsumieren muss (Flusskontrolle der Ausführungsmaschine). Das hängt davon ab, ob es sinnvolle Anwendungsfälle gibt gegenüber einem automatischen Konsum der Eingabeparameter durch die Ausführungsmaschine.
  • QuickWatch sollte automatisch auf allen Datentypen per ToString() funktionieren. IPlugins sind nicht für das Konvertieren von Datentypen in eine QuickWatch-Ansicht zuständig.
    • Denkbar: Ein Interface IQuickWatch mit Methode ToQuickWatchString() für komplexe, eigens definierte Datentypen.
  • Falls dynamische Elemente weiterhin notwendig sind (dynamische Properties, dynamische Settings), sollten diese ohne die indirekte 'Methodenname als string -> Methode' Referenzierung implementiert werden.
    • Entscheidend ist, a) dass es entweder eine einzige Stelle gibt, die man ändern muss, oder b) dass es schon zur Compile Time einen Fehler gibt, wenn man eine Stelle anzupassen vergisst. Der Fehler sollte nicht erst zur Laufzeit aufffallen.
    • Vgl. Problem bei Dynamic Combobox: as cast -> ergibt null. Falscher Rückgabetyp wird nicht abgefangen und löst Fehler in CrypWin.TaskPaneCtrl.AddOutputControls (bei DynamicComboBox -> inputControl ist null).
    • Mögliche Implementierung: Methodenaufruf AddDynamicProperty(THIS_IS_A_CONST_KEY, new ValueObject()). Um bei generischen Get/Set-Methoden Typsicherheit zu erhalten, müsste man mit Generics arbeiten. Ist nicht 100%ig sicher, aber deckt die meisten Fehlerfälle ab.
    • Welche Anwendungsfälle gibt es für dynamische Element? Kann man auf diese evtl. ganz verzichten, z.B. durch ein anderes Feature (z.B. Visibility Toggle)? Dynamische Elemente machen den Plugin-Entwurf durch die Indirektion komplexer und sollten vermieden werden, falls sie nicht zwingend notwendig sind.
    • Dynamische Settings notwendig?
  • Das Plugin muss bei den Eingabeparametern unterscheiden können, ...
    1. ... ob ein Dateneingang verbunden ist oder nicht (bislang: is null? siehe dazu auch #81)
    2. ... ob an einem Eingang ein Datum anliegt oder nicht (bislang: is null?)

Anforderungen an Settings

  • Reihenfolge der Settings ergibt sich aus der natürlichen Ordnung der Properties im Code (kein order-Parameter) -> schon geprüft, nicht möglich, da .NET keine Ordnung der Attribute garantiert
  • HasChanges wird automatisch behandelt und nicht in jedem Plugin separat -> schon implementiert
Last modified 8 years ago Last modified on Nov 28, 2011, 11:25:36 PM