Schnittstelle zum UI...

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

Guten Morgen!

Ich hänge mal wieder in einer Schleife, weil ich nicht so recht weiß, wie 'man' es denn nun richtig macht... :(

Es geht darum, wie eine Schnittstelle zwischen Daten (in meinem Fall Kalendereinträge) und UI aussehen könnte. Status Quo bei mir ist folgender:
  • Klasse Diary() nimmt Kalendereinträge (Entry()-Exemplare) auf und stellt Methoden zur Verarbeitung bereit
  • Klasse DaySheet() nimmt entries zu einem bestimmten Datum auf und bekommt zudem einen Verweis zur Diary.update()-Methode, damit Änderungen erfolgen können.
Mir stellt sich jetzt zunehmend die Frage, ob es nicht sinnvoller wäre, auf DaySheet() als Vermittler zu verzichten und gleich das Diary()-Exemplar an die UI zu übergeben. Der Grund ist der, dass es mit einem Verweis zu Diary.update() nicht getan ist. Aus der UI heraus möchte man ja auch Einträge erstellen, löschen oder auch weitere Daten anfordern. Das hieße ja, dass ich am Ende Verweise auf fast alle Diary()-Methoden bräuchte. Und das nur der Trennung willen?

Welche sinnvollen Möglichkeiten gibt es, um aus der UI mit Daten zu 'hantieren'?

mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Generell würde ich da für den Einstieg mal das MVC-Pattern ausprobieren (einfach mal googeln :-)

In den theoretischen Beispielen werden da immer Signale zur Kommunikation benutz. Das find ich in Python für kleine Projekte aber etwas zu sehr mit Kanonen auf Spatzen geschossen, weil man statt Signalen einfach Methodenaufrufe verwenden kann.

Im Endeffekt sieht das dann nachher so aus, dass du drei gekapselte Komponenten hast: Die Datenbank (wie auch immer du den Kram speicherst) und alles, was mit speichern und laden zu tun hat; das Frontend, also alles, was der Nutzer sieht bzw. was mit ihm interagiert; und als Vermittlerschicht einen Controller, der auf Befehle vom Frontend wartet und entsprechend antwortet.

Für simple Projekte kann man meiner Meinung nach den Controller auch weglassen, vor allem, wenn es nur ein Frontend geben soll -- man muss da nicht immer 100% formalisiert rangehen. Allerdings lohnt es sich, am Anfang "krankhaft strikte" Abstraktionen zu benutzen, um zu lernen, was wo hin gehört :-)

Ad Verweise zu Methoden: Es ist üblich, dass man einfach das Objekt mit den Methoden übergibt. Und das Frontend interagiert dann eben direkt mit den Methoden/Attributen des Objektes.

Hoffe das hilft :-)
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

Dauerbaustelle hat geschrieben:Generell würde ich da für den Einstieg mal das MVC-Pattern ausprobieren (einfach mal googeln :-)
Genau damit befasse ich mich gerade und lese ja auch hier immer wieder mal den Tipp, zumindest Daten und UI zu trennen.
Dauerbaustelle hat geschrieben:Ad Verweise zu Methoden: Es ist üblich, dass man einfach das Objekt mit den Methoden übergibt. Und das Frontend interagiert dann eben direkt mit den Methoden/Attributen des Objektes.
Danke. Genau sowas wollte ich hören. Ich neige leider dazu, die Dinge päpstlicher als der Papst zu nehmen. Und wenn man eben noch sehr wenig Erfahrung hat, dann hilft einem so ein Ratschlag manchmal mehr als die Lektüre noch so vieler theoretischer Abhandlungen.

Nun ja, jetzt werd' ich mal weiter versuchen, mir eine Vorstellung zu verschaffen, wie das MVC Pattern sinnvoll auf meinen Kalender angewendet werden kann.

Weitere Fragen sind garantiert! :P

mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
Antworten