MVVM in der Realität

[stahli]

Zitat von Stevie:

Diese Eigenschaft gibt es aber nicht in einer TCombobox

Das mit dem EmptyString war nicht direkt auf eine Combobox bezogen (obwohl das dort auch Sinn machen könnte, wenn man auch freie Eingaben ermöglichen will).

Zitat von Stevie:

...außerdem wäre ich dann wieder im OI unterwegs, um irgendwelche Binding relevanten Dinge einzustellen. Und das wollt ich eher vermeiden bei dem Ansatz - ich will kein RAD-MVVM.

Ok, ich will das aber unbedingt. Es ist eben viel einfacher und schneller zu nutzen - jedenfalls wenn die IDE das gut unterstützt.

[Mavarik]

Zitat von Stevie:

ich will kein RAD-MVVM.

Ach nein... Komisch genau das will ich, daher wir von mir jede Komponente abgeleitet und die nötigen Einstellungen mit auf zu nehmen!

[stahli]

Du willst ja nix zeigen, aber dann haben wir offenbar den gleichen Ansatz oder zumindest Grundgedanken...

[QuickAndDirty]

Mir wäre es am liebsten wenn die IDE, Firemonkey und die Sprache dahingehend erweitert würden das MVVM sauber Unterstützung findet.
Z.B. fände ich eine Integration mit Photoshop oder ein eigenes Designtool für Firemonkey recht sinnvoll.
Es muss möglich sein Formulare vollständig ohne Programmierer zu entwerfen und zu animieren.

[Mavarik]

Zitat von stahli:

Du willst ja nix zeigen

Hab das nicht so "zum zeigen"... Ist alles zu sehr in ein Projekt integriert...

Bin noch dabei ein "Framework" daraus zu machen...

[mquadrat]

Zitat von stahli:

Kannst Du mal kurz skizzieren, wie Ihr die Aktualisierungswege in beiden Richtungen realisiert?
- Eingabe im Edit ändert den Wert in der Datenschicht (evtl. nach Validierung)
- Änderung von Daten durch Logik informiert Edit zwecks Neuzeichnung (müsst Ihr da z.B. Nachrichten in Settern versenden?)

Ist ne Weile her (im Moment mache ich fast nur PHP Projekte). Wir haben eine Zwischenschicht, in der alle Bindings registriert werden. Ist die eine Seite des Bindings ein Control hängt sich die Zwischenschicht automatisch an das passende Event, das bei einer Änderung ausgeführt wird. Dazu gibt es je Control-Klasse einen Adapter, der automatisch gezogen wird. Bei einem PODO als Quelle muss man sowas ähnliches wie eine PropertyChangedNotification aus .NET abfeuern. Ich hatte auch mal Konstruktionen ausprobiert, die die nativen Typen kapseln und die Notification dann selbstständig auslösen. Fand ich aber immer ziemlich sperrig. Dazu kommt, dass in unseren Legacy-Anwendungen sowieso schon so eine Notification in jedem Setter steckt, um prüfen zu können, ob ein Wert sich geändert hat und abgespeichert werden muss.

EDIT: Wenn ich mal Zeit habe, kann ich auch mal den Code raussuchen. Ist nicht besonders hübsch, aber funktioniert für unsere Zwecke. Veröffentlichung war mal geplant. Aber da fehlt aktuell einfach die Zeit (und ein XE8)

@Stevie

Um das Problem des Null-Werts kommen wir bei uns herum, weil wir dafür immer den Index -1 ohne Text nehmen. nil wird bei uns also je nach Control immer zu einem Leerstring oder eben zum Index -1.

[Dejan Vu]

Das mit dem 'Null'-Wert ist so eine Sache.

Ich finde es vollkommen ok, wenn in einer Auswahl 'A,B,C' auch die Option 'None' vorhanden ist. Dann spare ich mir sowohl die Logik, ein 'Selected'-Element nullable zu machen, als auch die Problematik, was denn angezeigt wird, wenn noch nichts ausgewählt ist. Und ja: Ich gebe dem Anwender die Möglichkeit, 'None' wieder zu wählen. Es gibt ja auch Radiergummis. Nur valide wird das dann vermutlich nicht.

Diese Vorgehensweise (Auswahlliste läst alle angezeigten Möglichkeiten zu. Nicht mehr und nicht weniger) entspricht genau dem Verhalten einer Checkbox. Das kann man sich ja auch als Combo mit zwei bzw. drei Auswahlmöglichkeiten vorstellen. Und wenn das so ist, kann ich auch die 'grayed' Version wählen.

Wir verwenden MVVM in einem Reporting-Framework, wo die Report-Klasse die Filtermöglichkeiten (definiert durch die Query) vorgibt. Aus diesen wird ein VM und die UI dynamisch generiert, ähnlich den Reporting Services. Hier haben wir oft beide Fälle 'Noch kein Filter vorgegeben', oder 'wähle alle aus'. Das Pattern ist für beide gleich: Die Auswahlliste wird entsprechend erweitert.

Letztendlich ist das aber Ansichtssache, ob man -ebenso wie bei Textboxen- die Möglichkeit bietet, ein Eingabeformular auf den Grundzustand zu setzen oder nicht.

[Stevie]

Das Problem hab ich bei meinem Ansatz ja nicht.

Aber ein CoC Ansatz hätte ihn mMn, denn dann muss ich die Zusatzinfos "gibts eine 'none' Auswahl" und "wie bekomm ich den displaytext für die Items" irgendwo her holen - wie? Ich kann die Argumentation "dafür ist das VM zuständig, denn das abstrahiert ja die View" verstehen, aber auf der anderen Seite gibt es bestimmte Dinge, die von UI zu UI unterschiedlich sind - und in solchen Fällen ist das im VM eher nicht gut aufgehoben, finde ich.

Genau aus diesen Gründen gibt's ja auch sowas wie extenders in KO.

[Dejan Vu]

Jetzt hab ich mir den Code doch mal angeschaut: Schön einfach und straightforward.

Was erscheint denn bei deinem Prototypen, wenn man noch kein Ticket ausgewählt hat? ('' wär ja auch was).

[Stevie]

Zitat von Dejan Vu:

Was erscheint denn bei deinem Prototypen, wenn man noch kein Ticket ausgewählt hat? ('' wär ja auch was).

Entweder der Text, den man bei BindOptionsCaption angegeben hat (in diesem Fall kann man auch wieder auf diese Option zurück wechseln) oder nix (ItemIndex = -1 und man kann nicht mehr auf "nix ausgewählt" zurück)