The above (when used on a content area or item) will show the value of a property (MP_PROPERTY) that is located on an object linked to the current object via GUID property (LK_LINKED_OBJECT).
== Why is NextLevel Properties and Commands not recommended? ===== 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 The performance impact of loading multiple levels of data (described in the section [[Why is NextLevel not recommended?]]). Instead, UBIK offers the safer alternative, CachedNextLevel, which presents NextLevel data only when it has been explicitly loaded, using stems from the command described work done in the next section; the LoadNextLevelCommand.<br>Data can be loaded background to the CachedNextLevel in two ways; * When the LoadNextLevelCommand is explicitly triggered.* When any NextLevel binding is present in the UI.<br>The loaded CachedNextLevel data can also be cleared in two ways; * By explicitly triggering the ClearNextLevelCommand.* By navigation, which clears the NextLevel data cacheload a page.
=== LoadNextLevelCommand ===When a customizing requires showing more data from Every time the children objects than the ContentListItemViewModel allowsuser navigates to an object, UBIK asks the recommended implementation is webservice to use deliver the LoadNextLevelCommanddata for that content page. This generates the If any NextLevel bindings are present in a customized UI, additional PreviewPageViewModels on demand, therefore reducing requests are made to load the server workload 'page' for each child. This means that would occur simultaneously and perhaps unnecessarily. The suggested usage when NextLevel is some kind of trigger control, such as used on a button or togglechild item template, that triggers the command and generates number of webservice requests is equal to the PreviewPageViewModel datachild count (which could be hundreds) + parent object, and at as opposed to only loading the same timeparent object, reveals the custom datawhich is UBIK's regular behavior.
An example The situation is worsened when the NextLevel bindings are used in the UI of one or more objects that are routinely used as intermediate points in a 'double level view' (which is hierarchy navigation. For example, if the colloquial term given users are very often clicking to customizings where navigate through a hierarchy 4 levels away from the root object, having NextLevelbindings on the UI of objects between these 4 levels may significantly increase the time spent waiting for each of those levels to load.Children Once the additonal webservice requests have been triggered, they are shown under children objects) queued and processed sequentially. This means that browsing through multiple levels, each with NextLevel bindings, can be found [[Showing Children / Documents under a Child|below]]trigger exponential numbers of webservice requests, all of which affects how soon server content arrives on the page.
=== ClearNextLevelCommand ===The ClearNextLevelCommand can be used to explicitly clear the NextLevel cached data. However, usage of this command is optional and not necessarily requiredat the same time, as simultaneos loading of multiple NextLevel we cannot deny that certain use-cases require that child data be displayed that is what impacts performance simply not directly accessible on the UBIK clientContentListItemViewModel. The next points outline alternate approaches that can deliver equivalent functionality, without compromising on performance.
<br>
== Performance Impact & Recommended Usage ===== Why is NextLevel not recommended? ===The performance impact following sections document the best ways to bind to various kinds of NextLevel stems data from the work done in the background to load a pagechildren objects.
Every time === NextLevel Properties and Commands ===In some cases, there may be no way around generating PreviewPageViewModels for the user navigates to children under an object, UBIK asks such as if the webservice user wants to deliver the data for that content page. If any NextLevel bindings are present in a customized UIbrowse their children or document items, additional requests are made to load the 'page' for each childwithout navigating into these objects. This means that when NextLevel is used on a child item template, The following commands outline the number of webservice requests is equal best way to the child count (which could be hundreds) + parent object, as opposed implement this behavior with least impact to only loading the parent object, which is UBIK's regular behaviorperformance.
The situation ==== NextLevel and CachedNextLevel ====Although NextLevel is worsened when the NextLevel bindings are often used in the UI of one or more objects that are routinely customizing, it is actually <b>not recommended</b> and should not be used as intermediate points in a hierarchy navigation. For example, if the users are very often clicking due to navigate through a hierarchy 4 levels away from the root object, having NextLevel bindings on the UI potentially significant performance impact of objects between these 4 loading multiple levels may significantly increase the time spent waiting for each of those levels to load. Once data (described in the additonal webservice requests have been triggeredsection [[Object_hierarchy_in_XAML:_NextLevel, they are queued and processed sequentially. This means that browsing through multiple levels_ParentLevel, each with _LinkedLevel#Why is NextLevel bindingsnot recommended?]]). Instead, can trigger exponential numbers of webservice requestsUBIK offers the safer alternative, CachedNextLevel, all of which affects how soon server content arrives on presents NextLevel data only when it has been explicitly loaded, using the command described in the next section; the pageLoadNextLevelCommand.
HoweverThe CachedNextLevel is simply a cache of NextLevel data that has been loaded already. Accessing this data is 'safe' in terms of client performance, at because, as described earlier, it is generally the same timeloading of multiple hierarchies of objects simultaneously, we cannot deny that certain use-cases require that child is where performance suffers. However, the method used to fill this cache is where customizers should be careful, as data can be displayed that is simply not directly accessible on loaded to the ContentListItemViewModelCachedNextLevel in two ways; * When the LoadNextLevelCommand is explicitly triggered. The next points outline alternate approaches that can deliver equivalent functionality* When any NextLevel binding is present anywhere in the currently loaded UI templates (any currently active ContentArea, without compromising on performanceChildArea, ChildItem, etc).
<br>
The first is recommended because it is a controlled and contained way for triggering load requests, whereas the second occurs unknown to the user and potentially triggers a large amount of unnecessary requests.<br>=== = 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 [[Showing Children / Documents under a Child |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 cache.<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.This command is additionally not required because navigating away from a page clears the cache automatically.<br> == How To: ===== Show NextLevel Children/Documents ===
This customizing is sometimes referred to as a 'Double Level View'.
</tabs>
<br>
=== Show NextLevel Child/Document Count ===
If a NextLevel binding is used to display a count of children or documents on an item in the child list, it can easily be replaced with a [[SYSCLS_CHILDINFOOWNER|ChildInfo classification]], that can easily be configured to display the number of Documents, or Non-document children.
In addition to being more performant, these bindings are more reliable, as they are calculated on the server instead of relying on local data.
Once the classification is added to the data model, the following bindings can be used:
* ClassificationHandler.ChildInformation - can be used to see whether any data is delivered (such as with a NullToColConverter).
* ClassificationHandler.ChildInformation.NumberOfNonDocumentChildren - gives the child count.
* ClassificationHandler.ChildInformation.NumberOfDocuments - gives the document count.
<br>
Examples of these bindings can be found in UBIK standard templates, such as in the UBIKObjectIndicators template found in UBIKThemes. === Showing Show Properties and Property details ===
{{Version/WinXSince|4.0}}{{Version/XamarinSince|4.0}} It is not necessary to use NextLevel Properties are now attached directly to the ContentViewModel, grouped under several useful collections, such as;
* Properties.VisibleItems - all delivered Properties that are not set as not [[Visibility|visible]] in the data model.
<br>
=== Data Engineering for Best Performance ===
At times, NextLevel is used because of a lack of knowledge of dedicated functionality already built into UBIK. Below are a few examples of common usages of NextLevel, and recommended alternatives.
<br>
==== Child / Document Count ====
If a NextLevel binding is used to display a count of children or documents on an item in the child list, it can easily be replaced with a [[SYSCLS_CHILDINFOOWNER|ChildInfo classification]], that can easily be configured to display the number of Documents, or Non-document children.
In addition to being more performant, these bindings are more reliable, as they are calculated on the server instead of relying on local data.
Once the classification is added to the data model, the following bindings can be used:
* ClassificationHandler.ChildInformation - can be used to see whether any data is delivered (such as with a NullToColConverter).
* ClassificationHandler.ChildInformation.NumberOfNonDocumentChildren - gives the child count.
* ClassificationHandler.ChildInformation.NumberOfDocuments - gives the document count.
<br>
Examples of these bindings can be found in UBIK standard templates, such as in the UBIKObjectIndicators template found in UBIKThemes.
[[Category:XAML|Object hierarchy in XAML: NextLevel, ParentLevel, LinkedLevel]]
