viewmodel access

2023-04-24

Wir entfernen den "lively"-Halo aus dem Reconciliation Branch.

Kontext

Frei nach Robin: Dem Halo lag die Annahme zu Grunde, dass man für eine real existierende Instanz einer Komponente, Verhalten dynamisch während des Entwicklungsprozesses (de)aktivieren möchte. In der Praxis stellt sich jedoch heraus, dass der reset, der entsteht wenn man eine neue Instanz der Komponente mit (bzw. ohne Verhalten) erzeugt wenn Verhalten (nicht) gewünscht ist, praktisch ist und man eigentlich nie auf der selben Instanz hin und her wechseln möchte.

Dies ist relevant, da das dynamische aktivieren und deaktivieren einer der Hauptgründe für die Idee der View-ViewModel Architektur war. Die grundsätzliche Möglichkeit der Deaktivierung von Verhalten hätten wir auch mit normalen Morphklassen, die bspw. durch die default-Klassen ersetzt werden könnten, wenn man Komponenten ohne Verhalten instanziieren will. Die View-ViewModel Architektur bringt uns also momentan vor allem noch eine sauberere Codeorganisation.

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.