Sir Rufo hat es auf den Punkt gebracht: 'überregulieren oder nicht'.
Will ich ein System, das leicht erweiterbar ist und vor allen Dingen stringent im Design, sollte ich dem Plugin nicht das Design der UI überlassen (irgendwie naheliegend). Ich erkaufe mir die schnelle Erweiterbarkeit mit Einschränkungen hinsichtlich des Designs, die aber gerade gewollt sind. In meinem Beispiel des Reporting-Frameworks war es so, das ich den Zeitraum der Auswertung (Von-Bis) immer an einer bestimmten Stelle im Frame haben wollte, darunter die Filial-Combo etc. Weiterhin gibt es für den Zeitraum ein bestimmtes Control, das mir sehr elegant erlaubt, einen Tag, die KW, Monat, Quartal etc. auszuwählen.
Wenn ich ein System designen will, bei dem das Hauptaugenmerk auf der UI liegt, wäre ich ja schön blöd, das so zu machen.
Nun ist es so, das ich bei einem Funktionsgenerator eher zu Szenario #1 tendiere, denn erstens sind die Einstellungen eher einfach, zweitens werden sie von keinem UI-Fetischisten bedient und drittens habe ich vielleicht Controls, die live-Änderungen sehr intuitiv durchführen und da wäre es wirklich von Vorteil, wenn diese Controls auch stringent genutzt werden. Weiterhin fände ich es wirklich elegant, wenn z.B. die Frequenz immer an oberster Stelle steht, gefolgt von Modularisierungseinstellungen, dann Optionen etc.
Nehmen wir als Gegenbeispiel ein Plugin-Framework für Analysen von Maschinensteuerungen, Logdateien etc. Also eine Wollmilchsau, die Eier legt und selber aufisst. Dort gibt es Kraut und Rübern, Äpfel und Birnen, will sagen, graphische und tabellarische Eingaben, Parameter, Auswertungen etc. Da wäre mein Konzept vollkommen fehl am Platz. Ich habe damals ein Interface verwendet, das ein Frame/Panel für Einstellungen geliefert hat. Das wurde dann beim Anklicken des Baumknotens auf die rechte Seite geklatscht. Eine Methode 'Execute' startet die Analyse und stellt die Ergebnisse in einem zweiten Frame/Panel dar. Ich war damit mehr oder minder an Delphi gebunden, aber mangels Alternativen in dem Laden war das nicht weiter schlimm.
Aber nicht immer ist für den gleichen Parametertyp das gleiche Control die beste Wahl. Vielleicht hast du zwei Int-Parameter, aber für den einen bietet sich eher ein Slider an und für den anderen eher ein SpinEdit.
Das sind im Fall #1 konstruierte Fälle, die in der Realität nicht auftreten. Vermutlich. Aber wenn die Ebene der Darstellung doch tangiert wird (Combo vs. Radiogroup) dann hat man vermutlich zuerst eine ensprechende Eigenschaft des Parameters, den man in der UI abbilden muss. Z.B. hier die Tatsache, ob der Wert punktgenau angegeben werden muss, oder eher ungefähr ('exact' vs. 'approximate'). Ein Notch Filter würde mir da spontan einfallen: Den regle ich nach Gehör/Gefühl. Hier ist ein Slider sinnvoll.
Wir haben hier also -entgegen deiner Annahme- wieder eine klare Trennung zwischen Funktion (Eigenschaft des Wertes:Exact vs. Approx) und Darstellung (Slider vs. Textbox/Spinedit)
Wenn ich jedoch Mühe habe, einem UI-Metapher eine entsprechende Eigenschaft eines Parameters anzudichten, sollte ich das Konzept überdenken. Ich kann mir z.B. keine Eigenschaft eines Parameters vorstellen, der steuert, ob ein Eingabefeld oder ein Spinedit genommen werden soll. Ist diese Freiheit gewollt?
Abschließend sei vielleicht noch angemerkt, das wir hier über einen Funktionsgenerator reden und nicht über ein komplettes konfigurierbares MVC-Konzept, das vielleicht nur mal am Rande.