Lebenszyklus in Eclipse Forms

Hat schon jemand den Lebenszyklus anhand der Doku des Interface IFormPart verstanden? Ich hab mal meine Gedanken dazu aufgeschrieben. Hier nochmal ein Auszug aus dem Javadoc zu IFormPart.

The form part has two ‚out of sync‘ states in respect to the model(s) that feed the form: dirty and stale. When a part is dirty, it means that the user interacted with it and now its widgets contain state that is newer than the model. In order to sync up with the model, ‚commit‘ needs to be called. In contrast, the model can change ‚under‘ the form (as a result of some actions outside the form), resulting in data in the model being ’newer‘ than the content presented in the form. A ’stale‘ form part is brought in sync with the model by calling ‚refresh‘. The part is responsible to notify the form when one of these states change in the part. The form reserves the right to handle this notification in the most appropriate way for the situation (for example, if form is in a page of the multi-page editor, it may do nothing for stale parts if the page is currently not showing).

Was sagt dieser Auszug nun aus? Erstens gibt es drei Zustände in denen sich ein IFormPart befinden kann. Ein normaler Zustand (Normal-State), einer wenn die Daten in der IFormPart vom Nutzer geändert wurden und damit neuer als die Daten im Modell sind (Dirty-State) und einer wenn sich die Daten im Modell geändert haben und die IFormPart noch die älteren Daten anzeigt (Stale-State).

Wie wirkt sich das jetzt auf die Implementierung eines IFormPart aus? Normalerweise stellt ein IFormPart einen bestimmten Ausschnitt eines Modells dar. Darin hat der Anwender die Möglichkeit, diesen zu bearbeiten. Als Basis für die Implementierung einer IFormPart gibt es die Klasse AbstractFormPart. Für die Bearbeitung in der IFormPart werden meistens Textfelder verwendet. Um nun der IManagedForm zu sagen, dass ein IFormPart in den Dirty-State gewechselt ist, muss nach einer Änderung des Textes im Textfeld die Methode markDirty() aufgerufen werden. Aus diesem Aufruf resultiert dann irgendwann ein Aufruf der Methode commit(). Innerhalb dieser Methode müssen Änderungen aus den Textfeldern in das Modell übertragen werden.

Die andere Richtung ist eine Änderung des Modells, wodurch die Anzeige innerhalb der IFormPart aktualisiert werden muss. Solch eine Aktualisierung ist häufig der Fall wenn man auf der einen Seite der IManagedForm eine Tabelle mit möglichen Modellelementen anzeigt und auf der anderen Seite für das gerade gewählte Modellelement eine IFormPart verwendet, in dem der Anwender die Eigenschaften des Modellelements bearbeiten kann. Dieses Layout heißt bei Eclipse Forms Master-Details-Layout. Die Tabelle mit allen Modellelementen ist der Master-Part und das IFormPart ist der Details-Part. Wie reagiert nun der Details-Part auf die Auswahl im Master-Part? Dazu muss der Details-Part das Interface IPartSelectionListener implementieren. Dieses Interface enthält eine Methode selectionChanged(), die bei einem SelectionEvent innerhalb der IManagedForm aufgerufen wird. Dieser Event wird ausgelöst, wenn der Anwender in der Tabelle ein anderes Modellelement auswählt. Für das Details-Part heißt der Aufruf der Methode selectionChanged() den Zustandswechsel in den Stale-State. Also sollte hier die Methode markStale() aufgerufen werden. Diese bewirkt ein Refresh des IFormParts. Innerhalb des Refreshs müssen die Textfelder mit den neuen Modelldaten aktualisiert werden.

Nach dem commit oder refresh wechselt das IFormPart wieder in den Normal-State und das ganze beginnt von vorn.

Schlagwörter: ,

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: