In Form1 auf eine in DataModul definierte TAction zugreifen

[sx2008]

Zitat von Harry Stahl:

Wenn man die Funktionen im Datamodule hat, kann man z.B. für das Programm unterschiedliche Oberflächen verwenden

Dann stell dir einfach mal vor du würdest das Datenmodul aus einer Konsolenanwendung heraus anwenden.
In diesem Fall merkt man nämlich dass eine Actionlist oder gar ein Actionmanager keine universelle API darstellt sondern in die Welt der Benutzeroberflächen gehört.

Oder anderst formuliert:
Angenommen man hat eine VCL-Anwendung und man möchte daraus zusätzlich eine Konsolenanwendung und einen Dienst der nur über TCP/IP kommuniziert ableiten.
Man würde also die Businesslogik extrahieren und in einen eigenen Namespace legen und getrennt von den 3 Anwendungarten aufbewahren.
Datenmodule gehören zur Businesslogik (bzw. zur Datenzugriffsschicht).
Aber die Actions, ActionLists und ActionManager müsste man entfernen denn schließlich sind diese Klassen in dem Namespace "Vcl.ActnList" bzw. "Vcl.ActnMan".

Man kann auch das Model-View-Controller Entwurfsmuster heranziehen.
Wohin gehören die ActionLists?
Ich würde sagen weder ins Modell noch in die View sondern ActionLists nehmen die Aufgaben von Controllern wahr.
Die ganze Architektur der VCL ist so aufgebaut, dass Delphi Steuerelemente gleichzeitig View- und Controller-Aufgaben wahrnehmen.
Ein Delphi Formular vereinigt sowohl View als auch Controller in sich, daher sind Actionlists auf dem Formular am Besten aufgehoben.

[Glühwürmchen]

Hm, nachdem ich mir Euer beider Argumente durchgelesen habe, neige ich dazu, Euch beiden Recht zu geben:

Der Grund, warum ich überhaupt auf die Idee kam, die Actionlist in das Datenmodule zu legen, war, dass ich deren Actions dann auf allen Formularen in der Anwendung verwenden kann, ohne immer die jeweiligie Unit in die USES-Klausel aufnehmen zu müssen.
Also angenommen, ich habe 20 Formulare und auf jeder liegt eine ActionList. Und dann baue ich ein 21. Formular zusammen, das Elemente jeden anderen Formulars in sich vereinigt (die Sinnhaftigkeit dessen sei jetzt mal dahingestellt), dann müsste ich im einen Fall 20 Units in die USES-Klausel packen und im anderen Fall nur das Datamodule.

Andererseits habe ich jedoch weiter oben beschrieben, dass ich, liegt die Actionlist auf dem Formular, wo deren Actions gebraucht werden, für jedes Ereignis einer Komponente eine eigene Action zuweisen kann, während ich in Dem Fall, dass die Actionlist im Datamodule liegt, nur das jeweilige Standardevent mit einer Action belegen kann und für die anderen Events einen Umweg laufen muss.
Darüber hinaus muss der Delphianer noch wissen, welches denn nun das Standardevent einer Komponente ist.

Das Standardevent eines Buttons oder eines MenuItems mag ja noch eindeutig sein. Aber was ist das Standardevent eines Panels oder eines Formulars?


Darf ich noch einmal an die Frage erinneren, welchen Vorteil die Verwendung des wesentlich komplizierter ercheinenenden AchtionManagers, der ja seine eigene Actionlist mitbringt, gegennüber der Verwendung einer einfachen Actionlist hat?

[Jumpy]

Keine Antwort zu der ActionManager-Frage, dafür noch eine (unausgegorene) Idee bzgl. Action auf Datamodul statt auf Formular. Wie ist es denn, wenn man die Action auf ein Basisformular packt, von dem alle anderen Formulare erben. Kann man die Actionlist dann benutzen?

[Glühwürmchen]

Vererbung!

Das ist eine gute, gangbare und ziemlich flexible Lösung.
Vielen Dank für den Tip.

[Dejan Vu]

Zitat von Glühwürmchen:

Vererbung!

Hmm. Ich habe eine Action 'Kundeninfo als Popup anzeigen'. Die habe ich im Hauptmenü als stinknormalen Menüpunkt, aber auch als Button in diversen Formularen in der Adresspflege, Auftragsannahme, Dispo etc. Welches Basisformular wäre das? Ich werde ja wohl kaum mein Hauptformular und meine Dispomaske von ein und demselben Formular ableiten und dort sämtliche Actionlisten, Imagelisten etc. platzieren, nur damit man die zentral verteilen kann. Igitt. Kann man in einer Desktopanwendung ruhig so machen, aber wenn die Projekte größer werden und oder sich auf verschieden Exen verteilen, wird das doch sehr häßlich.

Was spricht dagegen, diese Aktionen in einer eigenen Klasse zu verwalten? Wäre das nicht viel sauberer? Eine Action ist ja schließlich unsichtbar, hat also eigentlich nichts auf einem Formular zu suchen, denn im Formular sollten nur die sichtbare Komponenten liegen.

Also eine Actions-Klasse (TCustomerActions) wäre ziemlich fein. Diese Klasse verwaltet alle Aktionen, die ich mit einem Kunden so anstellen kann, sowie die Tooltips, Icons und sonstigen Schnickschnack. So, und wenn ich schon Komponenten hin und her schubse, dann packe ich sie mir eben in ein TDataModule, was eben mein visueller Container für meine CustomerActions ist. Vielleicht packe ich mir in die TCustomerDatamodule auch gleich meine Imagelist mit den Icons und meinen TsiLang-Übersetzer, der mir das alles multilingual macht. Klasse! Alles an einem Ort.

Das tolle ist ja, das so eine Action vielleicht auch etwas nichtvisuelles anstellt, z.B. die Kundendaten direkt auf den Drucker schicken. Dann kann ich das sogar vom Code an beliebiger Stelle machen, ohne in einer Unit plötzlich ein 'uses MainForm' machen zu müssen. Das verstößt ja gegen jeden Ordnungssinn.

Ich finde 'TDatamodule' ist ein unglücklicher Name für einen Container, der für die unsichtbaren Komponenten zuständig ist (TContainer fände ich besser). Ich kann so einen Container als Datenbanklayer bzw. Teil davon ansehen (eben eine Art Datamodule), oder als Actioncontainer, oder als Sammelsurium sonstiger Dinge, die konzeptionell zusammen gehören, und für die es eine Komponente gibt.

Ich habe z.B. die gesammte TCP/IP-Kommunikationslogik mit einem TCP-Server in einem Datenmodul drin. Was so ein Teil auf einem Formular zu suchen hat, frage ich mich bis heute. Cool. Das ist sogar komplett wiederverwendbar, was bei Plazierung auf meinem Formular nicht gegeben ist.

DevExpress bietet Templates für ihr Editoren an, damit steuert man das komplette Verhalten eines Eingabefeldes. Das packe ich mir in meinen TEditorTemplateContainer (was ein TDataModule ist), programmiere das durch und flansche es dort an, wo ich es benötige.

Die Zuweisung im OI mag an mancher Stelle etwas mühselig sein, vor allen Dingen, wenn man das Formular lädt, ohne das vorher der Container geladen ist (dann verschwinden die Verknüpfungen blöderweise). Aber ich habe mir angewöhnt, diese Verknüpfungen im Code eh explizit zu setzen, meist im FormCreate.

Das nur mal so als Anregung.