Changes
/* Why is NextLevel not recommended? */
== Why is NextLevel not recommended? ==
The performance impact of NextLevel stems comes from the work done in the background to load a pagean object.
Every time the user navigates to an object, UBIK asks the webservice to deliver the data for that content page. If any NextLevel bindings are present in a customized UI, additional requests are made and it is designed to load quickly deliver all the 'page' data for the current object. To maximize efficiency, and because any object could theoretically have hundreds of children objects, each child. This means that when NextLevel item is used on a child item templatenot delivered with its full scope of data, but rather, as the number of webservice requests is equal to the child count (which could be hundreds) + parent objectContentListItemViewModel, as opposed designed to provide only loading the parent object, which is UBIK's regular behaviormost commonly needed information.
However, if any NextLevel bindings are present in a customized UI, additional requests are made to also load the entire 'page'-worth of data for each child. This means that when NextLevel is used on a child item template, the number of webservice requests that are queued is equal to the parent object + child count (which could be hundreds), and the client must process each in turn. This is opposed to UBIK's regular behavior, which is optimized to only load the scope of one object, at one time.<br>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 hierarchy navigation. For example, if the users are very often clicking to navigate through a hierarchy 4 levels away from the root object, having NextLevel bindings on the UI of objects between these 4 levels may significantly increase the time spent waiting for each of those levels to load. Once the additonal webservice requests have been triggered, they are queued and processed sequentially. This means that browsing through multiple levels, each with NextLevel bindings, can trigger exponential numbers of webservice requests, all of which affects how soon server content arrives on the page.
For example, imagine a use-case where the user often has to navigate through the hierarchy to find an object they need to work on, which is 4 levels away from the root object. Any NextLevel bindings on the UI of objects between these 4 levels may significantly increase the time spent waiting for each of those levels to load, because once the additional webservice requests have been triggered, they are queued and processed sequentially. This means that browsing through multiple levels, each with NextLevel bindings, can trigger exponential numbers of webservice requests, some of which may not even be required, and together, all these add up to increase the time spent until server content arrives on the page.
<br>
However, at the same time, we cannot deny that certain use-cases require that child data be displayed that is simply not directly accessible on the ContentListItemViewModel. The next points outline alternate approaches that can deliver equivalent functionality, without compromising on performance.
<br>
[[Category:XAML|Object hierarchy in XAML: NextLevel, ParentLevel, LinkedLevel]]
== Recommended Usage ==
