Konzeptfrage: Interface oder Messages

[Ghostwalker]

Hi,

bin grad über einer etwas größeren Anwendung. Bisher existiert nur eine Hauptform und einige
Klassen fürs DB-Handling.

Aufbau:

Hauptform mit Hauptmenü und Statusbar, sowie 2 Bereiche für Frames. Einmal "Navigations"-Frames
sowie Content-Frames (über Tabset, es können also mehrere gleichzeitig offen sein). Da das einige
Frames werden, würd ich das ganze über eine Manager-Klasse verwalten. Zusätzlich kann ich das
so auch dynamisch handhaben.


Frage:

Die Frage, die sich nun stellt ist, wie baue ich die Kommunikation zwischen den einzelnen
Teilen auf (also zwischen Mainform, Navigationsframes und Contentframes), da hier ja
auch Daten und Commands ausgetauscht, bzw. angestoßen werden müssen.


Bisherige Ansätze:

a) Hardcore-Windows

Die Daten und Kommandos werden via PostMessage/SendMessage ausgetauscht, bzw. angestossen.

Vorteil:

- relativ einfach und schnell zu realisieren.
- flexibel

Nachteil:

- Unübersichtlich und damit schwer wartbar.

b) Interfaces

Jeder Frame implementiert (je nach Frametyp, also Navi oder Content) ein entsprechendes
Interface, das über einen zentralen Manager angesteuert wird.

Vorteil:

- Klare Struktur
- gute Wartbarkeit


Nachteil:

- Aufwendig zu realisieren
- schwieriger zu erweitern.



Hat jemand hier größere Erfahrung oder gar ganz andere Ansätze ?

[stahli]

Ich habe jetzt noch nicht verstanden, warum und was die Bereiche miteinander austauschen sollen.

Soll die Navigation so eine Art Ribbons werden, die abhängig vom aktuellen Content ist?

Sonst könnte die Navigation ja einfach stumpf einen eigenständigen Content öffnen.

Beschreib mal noch mehr oder zeige mal eine Skizze.

[Headbucket]

Ich habe es so verstanden: Es gibt immer 3 Bereiche, welche zusammenspielen müssen:

- Hauptmenü
- Navigationsframe
- Contentframe

Je nach aktuellem Programmzustand gibt es ein neues Set dieser 3 Bereiche. Eventuell teilen sich auch manche Sets das gleiche Navigationsframe usw.
Natürlich haben dann Aktionen auf dem Navigationsframe oder dem Hauptmenü Auswirkungen auf das Contentframe. Denn wenn ich auf dem Naviagtionsframe einen Button drücke, dann soll im Contentframe etwas passieren.

Eine Musterumsetzung würde mich auch mal interessieren.

Grüße
Headbucket

[TiGü]

Umsetzung geschieht mit den im Profil angegeben Turbo Delphi oder etwas neueren?

[Ghostwalker]

Jap, Umsetzung is mit TD unter XP (evtl Win 7)


Headbucket hat das ganze recht gut auf den Punkt gebracht.

(Mein Erklärbär is leider grad den Bach runter gegangen. Hab zu lange gebraucht ums zu tippen. )

[Ghostwalker]

So..jetzt aber, ein Beispiel: Fuhrparkverwaltung

Hauptmenü: PKW, Transporter, Fahrräder, Flugzeuge, Farben

Bei HM-Auswahl PKW:

Navi mit einer Liste der bestehenden PKW und Buttons für die Bearbeitungen/Ansichten

Bei Auswahl eines Elements und der Aktion edit:

Content:

Maske mit den Eigenschaften des gewählten PKW's


oder

Bei Auswahl eines Elements und der Aktion Belegung:

Content:

Maske mit der Belegung des PKW's und den möglich Aktionen darin


Bei HM-Auswahl Farben:

Content

Liste mit verfügbaren Farben für die entsprechende Eigenschaft
der Fahrzeuge/Flugzeuge incl. direkter Bearbeitung der Liste


Dabei ist z.B. der Navi relativ wurscht, ob nu PKW, Transporter oder Antigrav-Boards.
Sie muss nur wissen, das sie ne ID, ein Icon und einen Text als liste anzeigen soll und
welche Kommandos verfügbar sind.

Umgekehrt ists dem Content wurscht, woher ein Kommando kommt (Ob vom HM oder der Navi oder einer Batchdatei). Er muss nur wissen, das er jetzt das Item mit der ID xyz bearbeiten soll (z.B.).


Hoff mal das das ganze etwas verdeutlicht

[stahli]

Ich finde das schwierig.

Ich würde Dein Hauptmenü als Navigation bezeichnen.
Eventuell könnte man das in Form eines PageControls darstellen.
So kann der User in verschiedene Bereiche wechseln/navigieren.

Die Liste von PKWs würde ich nicht als Navigation bezeichnen, sondern als Master-Datenmenge.
Wenn dort ein Eintrag selektiert wird könnten neben der Liste Details in einem eigenen Bereich dargestellt werden.

Es wird also von außen nach innen immer detaillierter.
Dabei gäbe es aber keine Kommunikation von innen nach außen.
Durch Bewegen innerhalb des PageControls und innerhalb der Master-Listen werden dann einfach andere Detaildaten eingeblendet.

Offenbar willst Du etwas anderes erreichen, aber das habe ich noch nicht verstanden.

[Ghostwalker]

@stahli

Mit Master/Detail hast du schon nicht ganz unrecht. Wichtig ist im wesentlich das Master möglichst unabhängig von Detail ist und umgekehrt.

Master-PKW ist der gleiche wie Master-LKW und Master-Hoverboard. Die Details (oder besser das eigentliche Kernobject des Bereichs) sind aber unterschiedlich.

Beispiel:

MASTER hat immer 3 (Daten)-Element: id,status,text zur Darstellung.

Je nach Detail (PKW,LKW,Hoverboard) haben sie z.T. aber ganz andere Bedeutungen.

Beispiel zum Beispiel:

Der Master weiß, das er bei id xyz den Status grün anzeigen soll. Was "grün" bedeutet,
weiß er nicht (ist ihm auch egal).

Je nach Detail heißt "grün" aber bei einem PKW "Reifendruck ok", beim LKW "Druckluftkessel ok" und
beim Hoverboard "Akku voll" (hat weder Reifen noch Bremsen )

Ich kann also für PKW,LKW,Hoverboard den gleichen Master verwenden, obwohl es unterschiedliche Daten sind.

Dazu muss der Master aber mit Detail kommunizieren.

Master sagt Detail : Bearbeite Element mit ID xyz

Umgekehrt muss Detail aber auch mit Master kommunizieren:

Detail sagt Master : Neues Element mit ID abc Status:blau und Text: Wupti eingefügt.

[stahli]

Ok, langsam wird es klarer.

Drei grundsätzliche Fragen noch:

1) Die Liste von PKW und die Liste von LKW, liegen die persistent in Objekten vor oder werden die direkt über eine TTable aus einer Datenbank geholt?

2) Gibt es im Projekt immer fix eine PKW-Liste und immer eine LKW-Liste oder soll der User sich nach Bedarf beliebige Listenansichten erzeugen können? Ich hatte eine Eingangsfrage noch so verstanden.

3) Hast Du schon mal mit Interfaces gearbeitet?

[Ghostwalker]

@stahli

Zu 1)

Sie werden zur Laufzeit über entsprechende Objekte aus der DB zur Verfügung gestellt.


Zu 2)

Dynamisch. Der User bekommt Sortier-/Filterfunktionen. Daher auch entsprechende List-Objekte

Zu 3)

Jap. Zwar bisher eher im kleinen Rahmen, aber die grundsätzlichen Sachen hab ich kapiert