Please help us by completing this surveyGo to survey
Most of the operations done on Content in sensenet is governed via Actions. An Action is basically a command, instructing the system to use a specific component, a so-called Application, to display or modify the Content item addressed. To read more on the mechanisms and structure of Applications, see the page on the Smart Application Model.
Prerequisites: some of the features described in this article (about displaying content using 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.
In this article we go through these action types and look at their common use cases.
The Smart Application Model makes it possible to address Content with links pointing to them using their paths in the Content Repository. An
?action parameter can be used to select the application to handle the Content - in other words this parameter defines what to do with the Content. For example:
If a content item is requested without an action, it is equivalent to specifying the default action, which is Browse. Actions are more often referred to as the links that guide the user to the requested application page. An Action link is presented with an ActionLinkButton control that is a simple HTML link also displaying the requested Application’s link.
Actions are basically unlimited in number, builders can create Applications for specific, custom actions that the business scenario calls for. Available Actions on a Content are projections of defined applications for its Content Type. It’s not trivial to tell what Actions are valid for a specific Content item, as one needs to take into account all Applications defined for the Content Type of the item, as well as current user privileges on each of those and the item itself. The provided tools (ASP.NET controls available in the WebPages component) for displaying Actions natively handle the problem of available Actions:
If you do not have the WebPages component installed, our action framework still helps you constructing action links, so you do not have to assemble links manually.
The type of rendered Action is controlled by the application it referes to. The Application’s
ActionTypeName property defines the type (.Net class) of action to be rendered.
The REST API of sensenet is built on OData actions, and you can create your own custom ones too to extend this API.
In most cases it is sufficient to implement a custom operation as a simple method, the same way as you would write an ASP.NET Web API method. After putting a placeholder GenericODataApplication application in the appropriate folder in the Content Repository, you can start creating your custom method in your project. For the details, please check this article:
A Scenario is a group of actions one usually displays together. You can think of it as a context menu definition. A scenario is defined bottom-up, by setting the appropriate scenario keyword on each of the applications you wish to access. sensenet has a powerful caching system in place, enabling it to collect all needed actions in a scenario in a flash.
The action controls above (for example the ActionMenu) are able to filter and display actions by scenario. The action framework API also lets you query actions this way. See examples below.
The Action URL can contain a parameter called
back. The portal uses this value when there is a need to return (redirect) to the previous page after an operation - e.g. editing content properties. It is possible for portal builders to control the behavior of actions: whether to include the backurl or not. The default behavior of the portal is the following: all actions contain the
backurl parameter except the Browse action.
You can control the visibility of the back url parameter in the following places:
IncludeBackUrlfield to Default, True or False.
IncludeBackUrlproperty that you can set. This overrides the value that is given in the application.
IncludeBackUrlthat you can set. This overrides the value that is given in the application.
It is recommended that you set this value to False in your application content if you are sure that the user will not return after visiting that application but will continue to browse the portal ‘forward’ and the back parameter is not necessary. Otherwise URLs can grow long and can cause unexpected browser behavior.
The Action URL can contain a parameter called
backtarget. The portal uses this value in a similar way as the back URL above: where to redirect the user after completing the task on the page. The difference is that the
backtarget parameter values are not exact URLs but tokens that can refer to a certain junction on the portal. The available tokens are the following:
If a back target value is given in the URL the portal will use it instead of the back URL. The only exception is when the action was not completed (e.g. when a user hits the Cancel button on a content creation page); in that case the back URL will be used (if exists).
Some example action links may be:
There is nothing more to creating a Scenario than making up a name (keyword) for it, and adding it to all the applications you wish to access through it. Action presenter controls and Action query API calls usually accept a Scenario name, and automatically list all valid Actions found under that name.
Say, you wish to create a forum control panel, which will enable moderators to edit or delete Posts, and to lock or move Topics. First of all, you need a name for the scenario. ForumAdmin seems fine.
In our example, the applications for Posts and Topics are distributed as such:
You simply enter the
ForumAdmin keyword in the Scenario field of all the applications above. Now the appropriate actions will be displayed for moderators when they open the admin console. Note however, that you placed the Delete action for GenericContent in the Scenario, which means it will also display for Topics. To hide it, you simply need to deny the Delete permission on Topics for the moderator group. This way, the Delete action on Topics will become unaccessible, and will not show up in the menu.
This also helps make your system more secure. Simply not showing a command in a menu does not offer real protection. To deny a certain action for a group of users, the preferred way is to use User rights management.
Is something missing? See something that needs fixing? Propose a change here.