We have already introduced DependsOn to the dev community in our previous article. We took a story-like approach last time, but this time we’ll take a closer look at the architecture of the library to see what advantages it brings to AEM developers.
A Journey to the Core…
Below is a diagram showing the various parts of DependsOn. Though a bit simplified, it displays an early prototype of the library and shows how it has evolved.
Depends On Structure
The left side of the diagram depicts the starting point of our project, which forms its core. Here in particular you see ObservableReference – an abstract entity implementing the observable pattern. The ObservableReference has a built-in cache intended to reduce the number of calls to the real widgets and only notify the observers when the tracked widget values change.
ObservableReference runs two kinds of references supported by DependsOn. The first one is ElementReference – an entity that helps track a single field. This kind of reference is capable of handling the “real” HTML form elements, and monitoring and retrieving their values. The other one is GroupReference. The library uses it for processing element groups that are referred to with the @@name syntax. Inside the group reference, there’s a tracking mechanism for a set of named ElementReference-s matching the provided scope (the entire dialog or one of its nested containers). The value of a GroupReference is therefore an array; each array item is tracked by its own ElementReference.
Having said that, we need to mention several features that allow developers to debug pages powered by DependsOn from inside the browser.