viewmodel access

2023-04-04

Wir definieren best-pratices für das Accessing von ViewModels und wollen einen neuen ObjectEditor.

Kontext

Linus fragt sich, ob ein Signal auf einem ViewModel, dass exposed wird, auch auf dem morph signalisiert wird. -> koennte man machen, tun wir aber nicht. Robin sagt, er ist generell noch nicht so richtig glücklich mit der Aufteilung/dem Accessing von ViewModels und View und dass es in alle Richtungen immer hin und her gehen kann.

Wir kommen zu folgenden Einsichten:

1. Morphs erlauben direkten Zugriff auf Verhalten, das ist cool.
2. ViewModels erlauben das Wiederverwenden von verhalten für verschiedene Views und außerdem ein leichtes Abkapseln von Verhalten für direct manipulation workflows. Das ist ebenfalls gut.

Aus 1 folgt, dass ein Nutzer einer Komponente eigentlich nicht wissen müssen sollte, dass sie ein ViewModel hat. Alles was von außen zugänglich sein sollte, sollte also exposed werden! Im Beispiel mit dem signal von oben, macht es also Sinn, auf dem view yu signalen und nicht auf dem ViewModel.

Darauf folgt aucht, dass man den .viewModel accessor eigentlich nie verwenden sollte, und auch nicht die Option model in einem binding anzugeben.

Robin ist zu dem Eindruck gelangt, dass viele der Probleme die Rick mit den neuen komponenten hat daher kommen, dass er den ObjectEditor nicht mehr benutzen kann. Wir wollen einen bauen, der auch mit ViewModels umgehen kann. Die wichtigsten Eigenschaften des ObjectEditors waren, dass er es einfach ermöglicht hat neue Klassen zu definieren, ohne sich um Module kümmern zu müssen, und dass this immer sinnvoll gebunden wurde.

Es besteht dann nach wie vor die Schwierigkeit, dass man nicht mehr direkt z.B. this.extent machen kann an den meisten Stellen im Verhalten, sondern eben this.view.extent, weil es auf dem ViewModel implementiert ist. Das halten wir für zumutbar.