Changes
/* NextLevel and CachedNextLevel */ Better explanation for why LoadNextLevelCommand is better than NextLevel bindings.
==== NextLevel and CachedNextLevel ====
Although NextLevel is often used in customizing, it is actually <b>not recommended</b> and should not be used, due to the potentially significant performance impact of loading multiple levels of data (described in the section [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#Why_is_NextLevel_not_recommended?|Why is NextLevel not recommendedRecommended?]]). Instead, UBIK offers the safer alternative, CachedNextLevel, which presents NextLevel data only when it has been explicitly loaded, using the command described in the next section; the LoadNextLevelCommand.
The CachedNextLevel is simply a cache of NextLevel data that has been loaded already. Accessing Simply accessing this data is 'safe' in terms of client performance, because, as described earlier, it is generally the simultaneous loading of multiple hierarchies of objects simultaneously, that is where causes performance suffersto suffer. HoweverTherefore, the method used to fill this cache is where customizers should be careful, as data can be loaded to the CachedNextLevel in two ways; * When the LoadNextLevelCommand is explicitly triggered(ie., the correct way).* When any NextLevel binding is present anywhere in the currently loaded UI templates (any currently active ContentArea, ChildArea, ChildItem, etcie. the 'bad' way).
<br>
The first LoadNextLevelCommand technique is recommended because it is a controlled and contained way for of triggering load loading requeststhat is controlled and contained. The second technique is problematic because it will occur on any currently active template (such as ContentArea, whereas ChildArea, ChildItem, etc., with item templates being the second occurs unknown worst scenario), that binds to NextLevel; * without the user knowing: the UI is simply unresponsive while loading, * without being in their control: there is no way to not trigger the loading, if they are currently not interested in the NextLevel data, and * potentially triggers for a large amount number of unnecessary requestsobjects: if the NextLevel binding exists on the item template used by many children items, increasing unresponsive time.
<br>
[[Category:XAML|Object hierarchy in XAML: NextLevel, ParentLevel, LinkedLevel]]
==== LoadNextLevelCommand ====
When a customizing requires showing more data from the children objects than the ContentListItemViewModel allows, the recommended implementation is to use the LoadNextLevelCommand. This generates the additional PreviewPageViewModels on demand, therefore reducing the server workload that would occur simultaneously and perhaps unnecessarily. The suggested usage is some kind of trigger control, such as a button or toggle, that triggers the command and generates the PreviewPageViewModel data, and at the same time, reveals the custom data.
