Wohin mit den Nicht-Visuellen Komponenten?

[mkinzler]

Dann muss man aber auch alle Einstellungen im Code setzen

[Stevie]

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form. Hast du allerdings Dinge, wie DBConnection, Datasets (über Datasources müsst ich nochmal nachdenken, wo die für mich hingehören) kann man die in ein DataModule packen. Allein um Wiederverwendbarkeit und Trennung von GUI und BL zu gewährleisten.

P.S. Ich hasse das Erzeugen von Komponenten im Code, wenn man sie auch im Designer platzieren könnte...

[Ralf Kaiser]

Zitat von Stevie:

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form.

Das sehe ich ein wenig anders.

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik. Fügt man diese in ein Datenmodul ein so hat man die Logik in diesem Modul "gesammelt" und von der GUI, also dem Formular, getrennt.

(wobei z.B. OnUpdate-Methoden eventuell da eine "Grauzone" darstellen)

[jaenicke]

Zitat von mkinzler:

Dann muss man aber auch alle Einstellungen im Code setzen

Richtig, und das ist auch gut so. Sonst wundert man sich plötzlich warum irgendetwas nicht mehr geht, dabei hat nur jemand aus Versehen eine Eigenschaft umgestellt.

Bei größeren Projekten wird das allerdings auch unübersichtlich, wenn man das nicht gut kapselt. Deshalb ist es nicht so eindeutig was wo sinnvoll ist...

Klar ist jedenfalls eins:
Um die Oberflächen an sich von deren Logik sowie der Businesslogik und den Daten zu trennen, macht es Sinn alles auszulagern was nur geht. Wenn man das über mehrere Schichten macht, kann man leicht die Oberfläche auswechseln ohne deren Logik mit auswechseln zu müssen.

// EDIT:

Zitat von Alfi001:

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik.

Naja, eigentlich ja nicht direkt. Die entsprechenden Handler geben das ja nur (etwas aufbereitet) an die eigentliche Oberflächenbehandlung weiter.

[Neumann]

Ich würde die nichtvisuellen Komonenten auch möglichst in Datamodule oder auch auf normale Forms, die nie angezeigt werden auslagern.

Wenn es nicht geht (z.B. Mainmenu hab ich noch nicht versucht) dann kann man GExperts installieren, mit dem man diese Komponenten bei Bedarf sichtbar/unsichtbar machen kann.

[mkinzler]

Ein Menü ist ja auch irgendwie visuell

[stahli]

Das MainMenu hatte ich früher in einem DataModule liegen. Angezeigt wurde es ganz normal im MainForm.
Ich fand aber praktisch, dass das Icon während der Designzeit nicht auf dem Formular rumlag.

Diese Konstellation hat jedoch während der Entwicklung ständig die MainForm-Höhe verringert...
Das Formular wurde immer beim Öffnen (oder war es Speichern?) des Projektes um 20 Pixel oder so verkleinert.

[Stevie]

Zitat von Alfi001:

Zitat von Stevie:

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form.

Das sehe ich ein wenig anders.

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik. Fügt man diese in ein Datenmodul ein so hat man die Logik in diesem Modul "gesammelt" und von der GUI, also dem Formular, getrennt.

(wobei z.B. OnUpdate-Methoden eventuell da eine "Grauzone" darstellen)

Ich sagte ActionList, und nicht die Events davon... Angenommen, du hast nen MenuItem im MainMenu, eins in nem PopupMenu und noch nen ToolButton. An alle 3 kommt die gleiche Action. Dann kommt das Event ins DataModule (oder sonstwo hin, aber nicht ins Form!) aber die ActionList kann locker aufm Form bleiben.

[Jazzman_Marburg]

Merci!

Gruß
Jazzman