...und an einen Fusionsreaktor gedacht,...
Mit Plugin-Schnittstelle, wo man die unterschiedlichen Fusionsreaktortypen andocken kann. Mit Hot-Plug zur Laufzeit.
wo das Plugin seine Bedienoberfläche hinmalen kann, wie auch immer das Plugin das für richtig hält.
Dann hätten wir wieder eine kunterbunte UI, wo der eine Checkboxen verwendet, aber der andere einen Wippschalter etc.
Das, was du an Interfaces definierst, entspricht halt ziemlich genau dem, wie auch die
VCL schon aufgebaut ist (Checkbox – Boolean, Edit – String etc...).
Das ist es gerade *nicht*. Das eine ist das Model, das andere die View. Ich definiere ja nur z.B. eine Selektion (eine Auswahl aus einer Liste). Wie das dargestellt wird, ist dem Funktionsgenerator ja schnurz (Combo, Radiogroup). Genauso verhält es sich mit einem Double. Soll das eine Maskedtextbox werden? Von mir aus? Ein Slider? Auch gut, ist eh Sache der View. Das Plugin hat damit nichts am Hut.
Zitat:
Dazu kommt, dass die
GUI so irgendwann unübersichtlich werden wird, wenn es mehr als eine Hand voll Einstellungen gibt...IPropertyGroup eingeführt, was eigentlich nur eine GroupBox-Repräsentation ist,
Sehr gut. Das Konzept von MVC. Ich bin damit doch von der konkreten Darstellung (
VCL, FMX,
HTML etc.) vollkommen unabhängig. Und wenn ich morgen DevExpress einsetze, sehen die Property-Sheets aller Funktionsgeneratorn gleich aus. Ich habe nur eine Stelle im Code, wo ich das anpassen muss. Was will man mehr?
Zitat:
Und an manchen Stellen will man vielleicht keine GroupBox sondern lieber TabSheets, und dann gibt es dafür auch wieder ein extra Interface. Verstehst du jetzt was ich mit
VCL nachbauen meine?
Nein. Denn ich habe genau das gerade gemacht: Property-List auf der einen Seite (Model und Viewmodel) und
GUI-Elemente auf der anderen Seite (Control-Renderer). Der Control-Renderer (also das, was Du mit '
VCL nachbauen' meinst, umfasst etwas mehr als die von mir skizzierten IF-Blöcke. Die
VCL hat meines Wissens nach ein paar Zeilen mehr.
Richtig ist aber auch, dass das Ganze nur dann Sinnvoll ist, wenn die Einstellungen nicht zu komplex sind. Bis ca. 15 Parameter sind ok. Gruppen und Tabs bekommt man aber noch problemlos hin. Wie gesagt, ich habe das gerade gemacht und es ist herrlich einfach und elegant: Es ist ein Reporting-Framework, wo man eigentlich nur die
Query sowie die Datentypen der Parameter angeben muss, sofern diese nicht aus einem Repertoire aus vordefinierten und registrierten Parametern kommen: 'select * from Tabelle where KundenNummer =:KundenNr' extrahiert die 'KundenNr' definiert ein 'ICustomerNumberProperty'. Das zugehörige ViewModel (hier wäre das ein Frame) ist auch hinterlegt und -bupps- fertig ist der Report. Bei 'select * from Foo where Bar =:Bar' muss man 'Bar' entsprechend deklarieren (z.B. Selection of 'BarFoo, FooBar, Slartibartfass') und fertig ist das Teil.
Hier wäre das eine
DLL, die eine Liste von Einstellungen exportiert und der Rest ist wie gehabt. Programmier das mal, ist wirklich super.