MVVM in der Realität

[Stevie]

Zitat von stahli:

Der Weg erscheint mir ehrlich gesagt (potenziell) stabiler und einfacher als der von Stevie.

Attribute sind einer von vielen Wegen. Du kannst auch in deinem FormCreate die ganzen Bind(...) Aufrufe tätigen wie ich oben doch bereits schrieb.

Und CoC birgt andere Hürden. Zum Beispiel wüsst ich gerne, wie man über die Benamung einer Combobox diese mit Objekten und deren Namen plus einem Caption ('Bitte wählen sie was aus') befüllt wenn im VM nur eine Property mit einer Liste dieser Items ist. Wo hinterleg ich die Info, dass der Anzeigetext der Name ist und ich dieses Zusatzelement als erstes habe, was "keine Auswahl" repräsentiert. Ins VM gehört diese Info mMn nämlich nicht.

[stahli]

Aus meiner Sicht gehören diese Infos (Vorgaben) optimaler Weise direkt in die Controleigenschaften. Also z.B. eine Eigenschaft: EmptyString = "hier Text eingeben".

Für andere Zwecke kann man z.B. global Zuordnungslisten ablegen, die das Framework dann benutzen kann.
Z.B. für einen Aufzählungstyp TSex = (sxMale, sxFemale) könnte man global Strings hinterlegen:
NIL="bitte wählen Sie aus"
sxMale="männlich'
sxFemale="weiblich"

Dann kann das Framework erkennen was welche Texte es z.B. in einer Combobox anbieten muss, wenn sie an ein Feld vom Typ TSex gebunden ist.
Auch das Schreiben des ausgewählten Wertes kann das Framework dann über die hinterlegte Tabelle vornehmen.

Mit den Standardcontrols ist das natürlich schwer zu realisieren. Aber man kann sich diese ganzen ViewModels, Controller und Registrierungen sparen.

[Sir Rufo]

@Stevie

Wenn es eine Auswahlmöglichkeit gibt, die besagt, dass aktuell nichts ausgewählt ist, dann gibt das das ViewModel vor. Die View stellt nur das Control und die statische Beschriftung.

[Stevie]

Zitat von Sir Rufo:

@Stevie

Wenn es eine Auswahlmöglichkeit gibt, die besagt, dass aktuell nichts ausgewählt ist, dann gibt das das ViewModel vor. Die View stellt nur das Control und die statische Beschriftung.

Würdest du dann nil (oder ein Null-Object) in die Liste der Möglichkeiten aufnehmen? Find ich eher suboptimal. Dass nil eine Auswahlmöglichkeit ist, ergibt sich ja aus der "ausgewähltes Element" Eigenschaft.

Zitat von stahli:

Aus meiner Sicht gehören diese Infos (Vorgaben) optimaler Weise direkt in die Controleigenschaften. Also z.B. eine Eigenschaft: EmptyString = "hier Text eingeben".

Diese Eigenschaft gibt es aber nicht in einer TCombobox - 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.

[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...