![]() |
AW: MVVM in der Realität
Zitat:
|
AW: MVVM in der Realität
schon genial gemacht. Ich habe auch lieber alles in der Code-Datei, anstatt alles im Formular reingebastelt. z.B. 3th-party Komponenten binde ich generell nicht in die IDE ein und erzeuge die lieber per Code.
@Stevie könnte man dein Beispiel auch um den VirtualStringTree erweitern? |
AW: MVVM in der Realität
Stevie plant ja für dieses Jahr, die MVVM Implementierung in DSHARP zu aktualisieren/weiterentwickeln und es gibt hier ja auch Freiwillige im Forum, die ihm helfen wollen. ;)
|
AW: MVVM in der Realität
Zitat:
Delphi-Quellcode:
aufruft. Außerdem verhält sich die IDE etwas nickelig, wenn man ein Control löscht, denn dann bleibt das Attribut in der Luft hängen - doof.
Bind(...)
Für den VST würde ich den DSharp TreeviewPresenter benutzen, dem man dann wunderbar eine Liste von Objekten geben kann und auf
Delphi-Quellcode:
binden kann.
SelectedItem
Zitat:
|
AW: MVVM in der Realität
Schaut auf jeden Fall eleganter aus, als das, was ich gebaut habe. Die Attribute finde ich gut, aber das Problem wird halt sein, dass die IDE im Designer damit nicht sonderlich gut klar kommen wird. Wir verwenden die meiste Zeit Konventionen als Binding. Sprich hat das Control den gleichen Namen wie eine Property des BindingContext, dann binde da automatisch dran. Und je nachdem was es für ein Control ist, wird halt gegen eine andere Standard-Eigenschaft gebunden.
Was ich noch anregen würde, wäre den Zugriff auf die Werte gegen die gebunden wird zu abstrahieren. In unseren Legacy-Anwendungen haben wir Getter/Setter statt Properties. Ich müsste also eine Zwischenschicht einziehen können, die wahlweise mit einer Instanz, die aus Properties liest oder eben mit einer, die die Getter/Setter verwendet, arbeiten kann. |
AW: MVVM in der Realität
Der Weg erscheint mir ehrlich gesagt (potenziell) stabiler und einfacher als der von Stevie.
Wenn man ein Control löscht gibt es eben nichts mehr, was dort irgendwas daran zu binden versucht. Im Fall von Attributen scheint es ja Probleme zu geben und wenn man Bindings im Quelltext definiert ist die GUI ja auch vom Quelltext abhängig. 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?) Die Frage ist ja entscheidend, wie komfortabel das Framework zu nutzen ist. So wie ich Dich bisher verstanden habe liegt Eure Lösung etwa auf meiner Schiene. Allerdings wäre natürlich eine Bindung an variable Controls und Controleigenschaften sinnvoll. |
AW: MVVM in der Realität
Zitat:
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. |
AW: MVVM in der Realität
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. |
AW: MVVM in der Realität
@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. |
AW: MVVM in der Realität
Zitat:
Zitat:
|
AW: MVVM in der Realität
Zitat:
Zitat:
|
AW: MVVM in der Realität
Zitat:
|
AW: MVVM in der Realität
Du willst ja nix zeigen, aber dann haben wir offenbar den gleichen Ansatz oder zumindest Grundgedanken...
|
AW: MVVM in der Realität
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. |
AW: MVVM in der Realität
Zitat:
Bin noch dabei ein "Framework" daraus zu machen... |
AW: MVVM in der Realität
Zitat:
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. |
AW: MVVM in der Realität
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. |
AW: MVVM in der Realität
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. |
AW: MVVM in der Realität
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). |
AW: MVVM in der Realität
Zitat:
Delphi-Quellcode:
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)
BindOptionsCaption
|
AW: MVVM in der Realität
Oh, bin wohl noch im Jetlag. Stand ja da: 'BindCaption'.
Ist zwar ok, weil der Text auch Sache der View ist, aber irgendwie auch nicht, denn das ergibt sich häufig auch aus dem Kontext der Auswahlliste. Aber wie man es dreht und wendet: Es ist so oder so korrekt und irgendwie auch nicht. Finde ich zumindest. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz