Changes
/* Recommended Usage */ Explained more about clearing the cachednextlevel automatically (and why it doesnt help the NextLevel situation)
In some cases, there may be no way around generating PreviewPageViewModels for the children under an object, such as if the user wants to browse their children or document items, without navigating into these objects. The following commands outline the best way to implement this behavior with least impact to performance.
<br>
==== 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 [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#Why_is_NextLevel_not_recommended?|Why is NextLevel not Recommended?]]). 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 a cache of NextLevel data that has been loaded. Simply accessing this data is 'safe' in terms of client performance, because, as described earlier, it is the simultaneous loading of multiple hierarchies that causes performance to suffer. Therefore, the method used to fill this cache is where customizers should be carefulactually the critical detail in terms of good performance, 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 (ie. the 'bad' way).
* 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 for a large number of objects: if the NextLevel binding exists on the item template used by many children items, increasing unresponsive time.
<br>
On every navigation, the CachedNextLevel is cleared, as what was previously the next level, becomes the current level. The frequency of this clearing and loading is part of the reason why customizers should pay close attention to the way they trigger these additional data requests, especially when navigation is involved.
==== 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.
An example of a 'double level view' (which is the colloquial term given to customizings where NextLevel.Children are shown under children objects) can be found in the How-Tos below.
<br>
==== ClearNextLevelCommand ====
The loaded CachedNextLevel data can also be cleared in two ways;
* By explicitly triggering the ClearNextLevelCommand.
* By navigation, which clears the NextLevel data cacheautomatically.
<br>
The ClearNextLevelCommand can be used to explicitly clear the NextLevel cached data. However, usage of this command is optional and not necessarily required, because, as previously stated, accessing the already-loaded data does not impact performance.
<br>
This command is additionally not required because navigating away from a page clears the cache automatically.
<br>
[[Category:XAML|Object hierarchy in XAML: NextLevel, ParentLevel, LinkedLevel]]
== How To: ==
