Sitefinity 3.6 new backend architecture - How to navigate between Views: Overview

[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]

 

 

Before we start to explain how to navigate between Views in the new backend architecture introduced in Sitefinity 3.6 we should recall the typical way of performing this task in previous versions of Sitefinity.

 

First of all, before we did not have Views, but rather we only had ControlPanel class. As we needed ControlPanel to perform several tasks depending on the action user has performed, typically developers would implement an enumeration on the ControlPanel which would represent available display modes. Then event handlers would make sure to switch the modes of the ControlPanel and ControlPanel would render appropriate controls based on the currently displayed mode. Following graphic displays this approach.

 

With the new architecture ControlPanel is just another View (admittedly an important one due to its root place in the hierarchy of Views).

The new approach - navigating Views

At any given time you will display one view which defines the user interface (actually, it is possible to display two or more views at once, but this is an advanced topic that should be used with utmost care and we will cover it later on).

 

The nice thing about this new architecture is that you don’t need to worry how all this will happen or better to say you don’t need to care about the details. All you have to tell Sitefinity is that you would like to display a particular view and Sitefinity will do the rest of the less interesting work.

 

The central idea is that you are navigating through Views not by postback, but rather but navigating to a URL which specifies the particular View. Again, Sitefinity provides a handful of methods which abstract away from you the process of URL generation.

 

We are distinguishing two rudimentary types of methods:

• Create and
• Navigate

For example, CreateCommand will return you a proper URL to navigate to a particular View, which you will generally use to assign the NavigateUrl property of HyperLink control. On the other hand, NavigateCommand will redirect user to a particular View. Navigate is generally used after some kind of operation has been completed (e.g. new blog post has been saved through postback) and you need to redirect user to a different view (e.g. blog post preview which displays the preview of just created blog post).

Conclusion

What we should take away from this article is that we are accessing Views through the URL. In order to access particular View we can use helper methods of the ViewModeControl class which will generate appropriate URLS. The benefit of this approach is that you can navigate directly to a particular view regardless of the context in which you are.

 

Imagine that you place “EDIT” link on the public BlogPosts control which is visible only to the logged in users. You can generate a correct link for each of these buttons that will take you to admin area and open the given post in edit mode. With the prior approach of postback driven UI generation this was, of course, impossible.

 

While it may appear obvious, it won’t hurt to mention that with this new approach you will obviously need to convert your LinkButton and Button controls which used to switch modes to HyperLink controls and assign them proper URLs. An example of such button is “Create new blog post”. Whereas before this button used to trigger postback and switch mode, now it will have to be replaced with hyperlink which navigate to a different View (namely PostNewView View).