auf Komponenteneigenschaften in Grijjy MVVM Starter Kit zugreifen

[jus]

Hallo,

aktuell versuche ich mich in das Grijjy MVVM Starter Kit einzuarbeiten. Ich verwende das Demo von Markus Kinzler als Grundlage. Doch wie kann man im ViewModel auf Komponenteneigenschaften der GUI wie z.B. ItemIndex von einer ComboBox zugreifen?

Wenn ich in der View folgendes mache, akzeptiert der Compiler es zwar klaglos, doch es passiert nichts:

Delphi-Quellcode:

procedure TViewDemo.SetupView;
begin
  inherited;

  //..

  Binder.Bind(ViewModel, 'SpezialItemIndex', ComboBox1, 'ItemIndex');

  //..
end;

Mein ViewModel sieht so aus:

Delphi-Quellcode:

TViewModelDemo = class(TgoObservable)
  private
    //..
    FSpezialItemIndex: Integer;
    //..
  public
     constructor Create(const Model: TModel);

    //..
    { ComboBox }
    property Entries: TEnumerable<TEntry> read GetEntries;
    property SelectedEntry: TEntry read FSelectedEntry write SetSelectedEntry;
    property SpezialItemIndex: Integer read FSpezialItemIndex write FSpezialItemIndex;
  end;

lg,
jus

[Schokohase]

Wie bekommt denn die View mitgeteilt, dass sich im ViewModel ein Eigenschafts-Wert geändert hat?

Im Demo passiert das wie folgt:

Delphi-Quellcode:

procedure TViewModelDemo.SetText(const Value: string);
begin
  if (Value <> FsRich) then
  begin
    FsRich := Value;
    PropertyChanged('TextChanged');
  end;
end;

Und in deinem ViewModel? Du schreibst den Wert einfach in das Feld und fertig. Das ist ein bisschen wenig.

[jus]

@Schokohase: du hattest recht, was Benachrichtigung seitens Viewmodel betrifft.
Das war aber nicht wirklich die Herausforderung. Das Problem war, dass die gebundene TComboBox.ItemIndex View-Eigenschaft im Viewmodel nie aktualisiert/benachrichtigt wurde. In DSharp MVVM konnte man mit "AddElementConvention<TCombobox>" die Binding Eigenschaften selbst erweitern. Da ich den Code von Grijjy MVVM aktuell noch nicht durchschaue habe ich brutal quick&dirty wie folgt die "Grijjy.Mvvm.Controls.Vcl.pas" angepasst:

Delphi-Quellcode:

procedure TComboBox.Change;
begin
  if Assigned(FOnPropertyChanged) then
  begin
    FOnPropertyChanged.Invoke(Self, 'Text');
    FOnPropertyChanged.Invoke(Self, 'ItemIndex');   // <--- hier erweitert
  end;

  if Assigned(FOnPropertyChangeTracking) then
  begin
    FOnPropertyChangeTracking.Invoke(Self, 'Text');
    FOnPropertyChanged.Invoke(Self, 'ItemIndex');   // <--- hier erweitert
  end;

  SetSelectedItem( Items.Objects[ItemIndex]);
  inherited;
end;

Das Viewmodel schaut dann so aus:

Delphi-Quellcode:

TViewModelDemo = class(TgoObservable)
  private
    //..
    FSpezialItemIndex: Integer;
    procedure setSpezialItemIndex(const Value: Integer);
    //..
  public
    //..
    property SpezialItemIndex: Integer read FSpezialItemIndex write setSpezialItemIndex;
  end; 
implementation
//..
procedure TViewModelDemo.setSpezialItemIndex(const Value: Integer);
begin
  if FSpezialItemIndex = Value then exit;

  FSpezialItemIndex := Value;
  PropertyChanged('SpezialItemIndex');
end;

Nun die Frage an die Experten, so wie ich die Grijjy.Mvvm.Controls.Vcl.pas angepasst habe, ist es im Sinne des Erfinders oder sollte man eher an einer anderen Stelle ansetzen?

lg,
jus

[Stevie]

Zitat von jus:

Delphi-Quellcode:

  if Assigned(FOnPropertyChangeTracking) then
  begin
    FOnPropertyChangeTracking.Invoke(Self, 'Text');
    FOnPropertyChanged.Invoke(Self, 'ItemIndex');   // <--- hier erweitert
  end;

Das muss wohl
FOnPropertyChangeTracking.Invoke(Self, 'ItemIndex'); // <--- hier erweitert heißen.

Sieht ansonsten aber nach genau der richtigen Stelle aus. Nur die Control Interposer Klassen können die Notifications Triggern, wenn man diesen Ansatz nimmt um das Feature als Drop-in zu nutzen und nicht extra binding aware Controls bauen möchte. Kurzer Blick in meinen DSharp Code geworfen... jup, ItemIndex und Text sind auch dort die Eigenschaften, über deren Änderung benachrichtig wird im Change.


Soweit ich das sehen kann, ist das Projekt aber auch derzeit nicht über den "netter Prototyp" Status hinausgekommen - mein ich keineswegs negativ.
Richtiges MVVM (und nicht, das was manche MVVM nennen) steht und fällt mit ner guten Databinding Lösung - und die schaut durchaus tauglich aus. Das ist auch zusammen mit dem TreeViewPresenter der Teil, den wir aus DSharp einsetzen.

Ich bin inzwischen der Meinung, dass wenn man zu ambitioniert versucht, MVVM so zu bauen, wie es in anderen Sprachen geht (deklarativ), fällt einem das zu schnell auf die Füße in Delphi, weils entweder wie bei Visual Livebinding einfach nur ein Riesengroßer unwartbarer Klump in den dfm Dateien wird außer man baut ein robustes Tooling drumrum, was massig Arbeit ist, so dass man das zur Designzeit schon auswerten kann - grad wenn man mit CoC arbeitet und Dinge automatisch binden lässt.

[jus]

Zitat von Stevie:

Zitat von jus:

Delphi-Quellcode:

  if Assigned(FOnPropertyChangeTracking) then
  begin
    FOnPropertyChangeTracking.Invoke(Self, 'Text');
    FOnPropertyChanged.Invoke(Self, 'ItemIndex');   // <--- hier erweitert
  end;

Das muss wohl
FOnPropertyChangeTracking.Invoke(Self, 'ItemIndex'); // <--- hier erweitert heißen.

ups, ja sollte so heißen

Zitat von Stevie:

Sieht ansonsten aber nach genau der richtigen Stelle aus. Nur die Control Interposer Klassen können die Notifications Triggern, wenn man diesen Ansatz nimmt um das Feature als Drop-in zu nutzen und nicht extra binding aware Controls bauen möchte. Kurzer Blick in meinen DSharp Code geworfen... jup, ItemIndex und Text sind auch dort die Eigenschaften, über deren Änderung benachrichtig wird im Change.


Soweit ich das sehen kann, ist das Projekt aber auch derzeit nicht über den "netter Prototyp" Status hinausgekommen - mein ich keineswegs negativ.
Richtiges MVVM (und nicht, das was manche MVVM nennen) steht und fällt mit ner guten Databinding Lösung - und die schaut durchaus tauglich aus. Das ist auch zusammen mit dem TreeViewPresenter der Teil, den wir aus DSharp einsetzen.

Ich bin inzwischen der Meinung, dass wenn man zu ambitioniert versucht, MVVM so zu bauen, wie es in anderen Sprachen geht (deklarativ), fällt einem das zu schnell auf die Füße in Delphi, weils entweder wie bei Visual Livebinding einfach nur ein Riesengroßer unwartbarer Klump in den dfm Dateien wird außer man baut ein robustes Tooling drumrum, was massig Arbeit ist, so dass man das zur Designzeit schon auswerten kann - grad wenn man mit CoC arbeitet und Dinge automatisch binden lässt.

ok, vielen Dank für die Rückmeldung Stefan!

lg,
jus