Smart Application Model is a feature of sensenet for defining both REST API endpoints and frontend templates to display and manipulate data in the
Content Repository. It enables portal builders to create a unique look and feel across content items while also saving time.
Some of the features described in this article (about displaying content with application Pages) are available only if you have the sensenet WebPages component installed, but the underlying philosophy of arranging applications, security and url generation applies even if you only have the core Services layer.
The classic approach in ASP.NET WebForms is to create Forms (Pages in sensenet) that will aggregate and display data based on their programmed logic. When you enter an address (eg. http://example.com/Default.aspx) into your browser’s location bar, it will be the address of a Form. This is pretty straightforward from a programmer’s viewpoint. You create logic - web applications - that are explicitly called and executed. However, from a user’s viewpoint, nothing can be farther from being straightforward.
Users are usually interested in content items (blogposts, videos, images, etc.), not the logic that can display them. The classic approach seen across the web is to request the desired content in a parameter, usually through the URL query string. This results in URLs like this:
Such URLs are not friendly to either users or search engines. The most prominent place in the URL - basically, the URL itself - is taken by the application, which should be a quiet servant to the content.
This approach is similar to starting a word processor from the Start Menu, and then opening a document from inside the software. A more intuitive way to work is to find the document you wish to edit, and double-click it. The operating system will automatically load the word processor, and open the document in it. And that is exactly what the Smart Application Model does in sensenet.
Here, you have URLs like the following:
Where “Great-day” is an actual content item (a blog post) located under the path “MyBlog/2010/08/Great-day”. Now, somewhere in the system there exists a Portlet Page, an ASP.NET application, that will display this blog post. We have simply hidden it from the eyes of the user, and put the content item itself into the lead role.
Data in the sensenet Content Repository is stored in a tree model, similar to a file system. Each item has a unique content path through which it can be accessed. However, as a single instance of sensenet can serve several sites with different content, we provide two URL schemes for addressing content items from the web.
The most common URLs used in a sensenet installation are site relative, sometimes referred to as friendly URLs. This means exactly what it says. Sites are content items themselves in the sensenet Content Repository, and a relative path points to content that is located inside the site it is accessed from.
For example, let’s say we have the following setup:
Usually, people will access this repository through one of the sites defined, the Cars or the Bikes site. Normally whatever follows the domain name in the URL will be the relative path of a content item under the site accessed.
Note that with absolute URLs, one can access a site through the domain name of another site in the sensenet Content Repository.
Addressing a content item is only half of the equation, you also need to say what you want to do with it. There are various operations one might execute on a piece of data.
In sensenet, what you want to do with a content item is called an
Action, and can be passed via the “action” query string parameter:
If a content item is requested without an action, it is equivalent to specifying the default action, which is Browse.
sensenet will load a different application depending on the action specified, therefore you can have a page for displaying a blog post to readers, one for editing it, etc. There is no limitation to the possible number and nature of Actions, so you can, and are encouraged to create entirely custom actions specific to your needs.
Possible actions may, as an example, include:
Similarly to Pages (that require the WebPages component to be present), OData actions can also be created to extend the REST API of sensenet. They can be defined in the same hierarchy and Content Type structure as old-fashioned Page applications. Follow the links below to learn more about them:
The Smart Applicaton Model goes further than just providing a friendly URL scheme. The real power lies in the complex logic that binds applications to content.
In sensenet everything is content and this includes the applications themselves. This means that the applications are located in the Content Repository either as
Portlet Pages or placeholder content items for logic (like HTTP Handlers) located in a DLL file.
Registering an application means placing it at the right place in the Content Repository, and naming it appropriately.
The way applications are resolved from the
Action specified in the URL is as straightforward as it gets. The application needs to be named the same as the Action. Eg. default applications must be called Browse, an application for Edit actions must be called Edit, etc.
Applications are located in a special
System Folder called (apps).
There can be an (apps) folder anywhere in the system, and when a content item is requested, the system finds the closest (apps) folder and looks at the applications that have been placed there.
If an appropriate application isn’t found, the system checks the second closest (apps) folder up in the tree and so on, until an application is found.
Like an operating system, sensenet also has types. The first layer of the binding logic does the same thing that your favorite OS would do to open the word processor for a document. It finds an application registered for the
Content Type of the requested item.
In fact, it goes one step further, as sensenet types have inheritance. Therefore, if an application isn’t found for the type in question, the system will check each of its ancestor types, until a registered app is found.
To registed an application for a specific
Content Type, you need to place it into a folder named after the type under an (apps) folder. Therefore, the path of a Browse application registered for the
HtmlContent type may look something like this:
Similar to binding by type, a set of
Smart Applications can be defined for a single content item, and that single content item only, by placing the
Smart Applications into a folder named This in the (apps) folder under the content item in question:
Smart Applications defined with a This binding have absolute priority in the resolution process.
Above we have looked at the three components of application binding. However, to work efficiently, you need to understand how they relate to each other.
The simplest part of the process is the action binding. The system will look for an application that is named exactly as the
Action specified. There are no fallbacks on this, if no application is found, an error message will be returned.
When a request arrives, the system will sequentially probe the (apps) system folders starting from the closest to the content item requested. In each (apps) folder, it will look for a folder that matches the type of the requested content item most closely (so parent content types are also in play!), while containing an application with the same name as the
Action specified. If not found, it advances on to the next (apps) folder, until a matching application is found, or it becomes apparent that such an application is not present.
See the following, simple content tree:
Note that all content types in sensenet are derived from
Let’s have a look at some requests that may arrive, and how the system handles them:
Here we have no
Action specified, which means that the default
Action will be used, which is Browse. This is how the request will be resolved:
Note that the Application placed in the This folder under the Content (Post2) itself overrides the
Applicationused in the case of Post1
Again, no action specified means Browse action.
Note that though there is a specific Browse application for BlogPosts, the GenericContent application placed in a higher position in the tree overrides it.
There is a way to override the above mechanism on a single content item. This is possible by setting the Default Browse Application field to an executable content item (
If set, the system will always display the content item using this application in Browse mode.
Before the introduction of the Smart Application Model, the preferred building block of
Portlet Pages. URLs would always point at
Portlet Pages or downloadable Files, with preset configurations or query string parameters specifying the content item(s) to be displayed.
You must know that this is still an option.
Portlet Pages can, and in certain circumstances, should, be used as primary content items to be directly addressed by the user. To help you decide when to do this, we have collected some disadvantages of the Smart Application Model, and select scenarios when addressing
Portlet Pages directly may be the best thing to do.
There is, however, a golden middle. By creating a Browse Smart Application with “This” binding, you can have the best of both worlds. This comes in especially handy when you need a unique, dashboard-like
Portlet Page to be displayed on a major container node, such as a
Site root or a
Workspace. Simply put, use
Portlet Pages for leaf content and “This” binding for containers.
Sitewithout using an absolute URL
The applications accessible to the user depends on permissions set on the applications and on the content itself. For more details on which permissions you should set on the applications and on the content, please visit the following article:
Is something missing? See something that needs fixing? Propose a change here.