Neben dem globalen Anpassen der Widget Defaults ist es auch möglich, Widget Implementierungen komplett auszutauschen oder zu dekorieren. Das globale Ändern eines Widgets kann durch viele Aspekte motiviert sein:

Beispiel 1:

Man möchte in einer Applikation Widgets, für welche man keine Leserecht besitzt, durch Fake Widgets ersetzen, welche die gleiche Schnittstelle implementieren, jedoch anstatt dem original Widget ein Label anzeigen, das Nutzter darauf hinweist, dass ein Recht fehlt. Zudem sollen keine Daten von dem zugehörigen Dienst eingelesen werden, weil dies sowieso zu einer Security Exception führen würde. Die jo-client-platform nutzt diese Möglichkeit zur Dekoration der BeanTable, des BeanRelationTree und weiteren Widgets. Der zugehörige IToolkitInterceptor findet sich hier

Beispiel 2:

Angenommen man möchte ein Testtool entwickeln, welches die Möglichkeit bieten soll, bestimmte Methodenaufrufe auf bestimmten Widgets eines bestimmten Typs zu protokollieren, während man eine Applikation bedient, um daraus Eingabedaten für einen automatisierten JUnitTest zu erstellen. Dann könnte man diese Widgets einfach durch einen Wrapper ersetzen, welcher die gewünschte Protokollierung durchführt, nachdem er die Methode auf dem Original Widget aufgerufen hat. Im Rahmen einer Bachelorarbeit wurde ein solches Testtool entwickelt.

Beispiel 3:

Ein weiterer Anwendungsfall könnte sein, dass man für das Debugging beim Layouten von verschachtelten Composites einen farbigen Border um alle Composites zeichnen möchte, um zu sehen, welcher Container in welche Schachtelungsebene welche Größe hat.

Im nächsten Abschnitt folgt ein weiteres, zusammenhängendes Beispiel.