Hierarchische Koordination aller Module:
Im Client ist das APP-Modul die "oberste Koordinationsstelle". Alle anderen Module sind direkt oder indirekt in den Zuständigkeitsbereich des APP-Moduls eingebettet.
Das APP-Modul agiert (wie jedes andere koordinierende Modul) nach einem strikten Regelwerk, dass eine "faire" Koordinnation gewährleisten soll. Auch wenn es seinen koordinierten Modulen Resourcen (Darstellungbereiche, ...) zuteilt, ist es nicht wirklich "übergeordnet" in dem Sinne, dass es die Resource-Zuteilungen "eigenwillig" durchführen darf.
Bei der Zuteilung der Resourcen werden die Resource-Anforderungen der koordinierten Module berücksichtigt und bei Bedarf nach dem Regelwerk des koordinierenden Moduls für die sich daraus ergebende Resource-Zuteilung priorisiert.
Module müssen ihre Darstellungen strickt auf den ihnen zugeteilten Darstellungsbereich beschränken:
Damit die Darstellungen konsistent sein können, muss sich jedes Modul strikt an die ihm zugeteilenen Resourcen (Darstellungsbereiche, ...) halten. Wie es sich daraus ergebende Konflikte löst, ist ihm dann aber völlig freigestellt.
Eine mögliche Lösung bei zu kleinen zugestandenen Darstellungsbereichen ist es, dass nur ein Teil der Darstellung sichtbar wird. Die restliche Darstellung wird "abgeschnitten". Es wird mit Hilfe der CSS-Anweisung overflow:hidden; quasi ein "Guckfenster" auf die Darstellung realisiert. Dieses Verfahren findet beispielsweise dann Anwendung, wenn die Darstellung eines koordinierten Moduls ganz oder teilweise unsichtbar sein soll - wie beim Ein- und Ausblenden des Bereichs zur Eingabe eines Suchtextes,
Eine weitere Möglichkeit zur Lösung bzw. Linderung von Resource-Mengen-Konflikten ist die Einrichtung von Scrollbereichen. Hier wird die CSS-Anweisung overflow:auto; oder overflow:scroll; eingesetzt. Dieses Verhalten wird dann eingesetzt, wenn die Nutzer mittels Verschieben den Blick auf den einen oder anderen Teil einer Darstellung werfen können sollen.
Eine noch weitere Möglichkeit wäre das "Zoomen" der Darstellung bzw. das Gegenteil (= Verkleinern) davon. Diese Option (mit CSS realisierbar per transform:scale(0.5); für eine Verkleinerung auf halbe Höhe und Breite) kann problemlos bei beispielsweise Fotos eingesetzt werden, aber bei anderen darzustellenden Informationen durchaus herausfordernd sein.
Vorgaben werden "top-down" abgearbeitet:
Wenn ein Modul andere Module "koordiniert", bedeutet das, dass anhand der Anforderungen und Möglichkeiten auf Basis eines Regelwerkes die Zuteilung der Resourcen stattfindet. Dieses geschieht "top-down" - also beginnend bei "obersten" APP-Modul über gegebenenfalls viele Modul-Ebenen bis hin zu den Modulen, die dann tatsächlich "Inhalte" sichtbar machen.
Anforderungen werden "bottom-up" abgearbeitet:
Die Zuteilung von Resourcen an ein koordiniertes Modul ist meist nicht unverrückbar. Ein koordiniertes Modul muss initial seinem koordinierenden Modul seine Resourcebedarfe mitteilen, damit es Resources zugeteilt bekommen, auch wenn diese (wie es meist der Fall ist) knapp sind.
Das koordinierende Modul sammelt alle Resourcebedarfe seiner koordinierten Module - und wechselt bei geänderten Anforderungen die Rolle in die eines koordinierten Moduls, das die neuen Resource-Anforderungen wiederum an sein koordinierendes Modul weitermeldet.
Dieser Vorgang verläuft "bottom-up" von den darstellenden Modulen bis hin zum APP-Modul.
Worauf ist bei der modulinternen Implementierung zu achten?
Bei der Umsetzung der Vorgaben sind zunächst die Werte für die Moduldarstellung als ganzes ("Layout") umzusetzen. Gegebenenfalls mit Konfliktlösungen durch teilweises Ausblenden, Scrollen oder Skalieren. Dabei kann automatisches (de)aktivieren des "Scrollen" und Skalieren problematisch werden und unnötiges "Geflatter" verursachen.
Sobald der Darstellungsrahmen des Moduls eingestellt ist, werden den koordinierten statischen eingebetteten Modulen ihre Resources zugeteilt.
Als letztes werden in einem (SPACE-) Modul den dynamisch eingebetteten Modulen (WIDGETs und abgeleitete Modularten) ihre Resources zugewiesen.
Bei der Zuteilung der Resources erfolgt KEIN SOFORTIGES Feedback zu den (geänderten) Bedarfen des koordinierten Moduls. Änderungen der Bedarfe müssen von den koordinierten Module explizit angemeldet werden, weil es sonst zu "race conditions" und/oder "Schwingungen" kommen kann.
Während die koordinierten Module ihre Vorgaben der Regel unverzögert/direkt (CALL -Aufruf) mitgeteilt bekommen, werden die Anforderungen der koordinierten Module in eine Warteschlange gestellt, die sequentiell abgearbeitet wird.
Falls nötig, eine periodische Überprüfung der Resourcebedarfe:
Wenn geänderte Resourcebedarfe in einem Modul nicht automatisiert Ereignisse auslösen können, kann sich das betroffene Modul zur periodischen Überprüfung (beim APP-Modul) anmelden und wird dann zwecks Bedarfsüberprüfung periodisch "geweckt"
Module (WIM) Darstellungen beim Client WIM-App-Verfahren (techn.)
