sensenet 7: this article has aon the new community site.
OverviewSmart Application Model that define the way specific Content are presented and processed when addressed. Building Smart Pages is done with Applications but there are also special Application types that do not appear in the form of pages and return with custom response. Applications can be invoked via Actions.
Presenting Content with Applications
The simplest way to present Content is done by placing portlets on individual pages that utilize Content presentational functionality (eg. Content viewer Portlet. However, Content can also be presented by addressing the Content itself and chosing an Application to present it. The selected Application is usually a simple page, that uses Context bound Portlets to handle the addressed Content. These Applications are also reffered to as Smart Pages and a single Smart Page in itself is capable of presenting many different Content of the same type. To create an Application (or Smart Page) create a new page under an (apps) folder in the Content Repository and use Context bound portlets for Content handling.
Path of the created Application bears special importance as it defines the range of Content it is applicable to. The path of an Application can be given in the form:
- custompath defines the path under which the Application will handle Content,
- contenttypename defines the type of Content that are handled by the Application, and
- applicationname is the name of the Application.
Applications can be overridden by placing an Application of the same name under an (apps) folder that is placed at a deeper level in the Content Repository and also by using the This keyword as contenttypename. See examples and refer to Smart Application Model for a details.
Applications and Actions
To connect Content and Application - besides properly setting up the Application Model in the Content Repository - so called Actions can be used. An Action in this case is a link that addresses the Content and specifies the name of the Application, for example:
The Application is resolved then using Smart Application Model mechanisms.
Altough an Application for a Content Type is usually defined as a Smart Page to present the Content, there are several other Application types defined in the system. An RssApplication for example will return the Rss feed corresponding to the addressed Content in the response. The base Content Type for Application types can be found under /Root/System/Schema/ContentTypes/GenericContent/Application. Here is a list of pre-defined Application types:
- ApplicationOverride: it can be used to override Fields of an existing Application (Smart Page), without modifying the page layout
- CaptchaImageApplication: renders a captcha image as the reponse
- GoogleSitemap: defines configuration for sitemap. Sitemap is returned by a custom handler.
- HttpEndpointDemoContent: a demo Content Type to demonstrate a Content that is able to customize response output when addressed.
- HttpStatusApplication: returns with the specified status code.
- ImgResizeApplication: resizes and caches the requested image according to set parameters and returns with the cached image in the response.
- RssApplication: returns the Rss feed for the requested Content in the response.
- Webform: base type for page-type Applications.
- XsltApplication: transforms the xml representation of the addressed Content with the specified XSLT and puts the output to the response.
- Scenario: the list of scenario 'keywords' that define the places where action links referring the Application will appear. For example an Application with ListItem scenario can be initiated from the dropdown menu in various lists; an Application with ExploreActions scenario appears in the Actions menu of Explore. You can read more about this at the Action reference wiki page.
- ActionTypeName: the type of action that is created when the Application is referred via an Action. Built-in types include:
- UrlAction (default): a simple link is created with ?action url parameter that points to the Application name.
- UploadAction: an UrlAction with custom check whether the link is rendered as enabled or disabled. Disabled if the context folder does not allow File types to be added as child Content.
- WebdavOpenAction: opens the context Content via Webdav. Useful for editing Word documents as the File will be opened with the associated application according to its extension.
- WebdavBrowseAction: opens the context Folder in Windows Explorer via Webdav. Folder Content can than be managed in Windows Explorer (uploaded, deleted, renamed, copied, edited, opened in Microsoft Word, etc.).
- ContentTypeAction: creates a link that brings up the Edit interface for the Content Type Definition of the context Content.
- CopyToAction: a simple link is created that brings up a Content Picker where destination Folder can be selected. Context Content is then copied using the CopyToTarget Application.
- CopyBatchAction: a simple link is created that brings up a Content Picker where destination Folder can be selected. Selected Content is then copied using the CopyToTarget Application.
- MoveToAction: a simple link is created that brings up a Content Picker where destination Folder can be selected. Context Content is then moved using the MoveToTarget Application.
- MoveBatchAction: a simple link is created that brings up a Content Picker where destination Folder can be selected. Selected Content is then moved using the MoveToTarget Application.
- DeleteBatchAction: a simple link is created that navigates to the DeleteBatchTarget Application with the selected Content.
- ContentLinkBatchAction: a simple link is created that brings up a Content Picker where destination Folder can be selected. Content Links for the selected Content are then created using the ContentLinker Application.
- CopyAppLocalAction: a simple link is created that calls a service that copies the context Application Content to a local (apps) folder of the current Content. The Application thus can be customized for the current Content independently from other Content under different paths in the Content Repository.
- DeleteLocalAppAction: a simple link is created that calls a service that deletes the context Application Content placed in the local (apps) folder of the current Content. A more general Application will be used to handle the current Content as the local Application that is being deleted.
- BinarySpecialAction: a simple link is created that navigates to the BinarySpecial Application. The action uses custom logic to determine whether the bianry content of the File can be edited with a textarea or not - in the latter case the action is not enabled (disables itself).
- Disabled: setting it true makes the Application 'disappear' and cannot be invoked through an action link. Applications on higher levels with the same name (those that were overridden by this specific instance) remain functional and take part in the Application path resolution logic.
- Clear: similar to Disabled, except that it hides higher level, overrided Applications of the same name as well. This is useful to disable an Application for a subtree when the Application has been defined on a higher level (eg. in /Root/(apps)) and is available for Content in several subtrees - but it should not appear for Content that are under a specific subtree.
- Icon: name of the Icon for the Application. This icon appears next to action links if it is enabled by the control that renders the link. Icons reside in the /Root/Global/images/icons folder.
- StyleHint: an optional string property that can interpreted by a custom renderer. Built-in renderers do not use this property.
- RequiredPermissions: multi select list that defines the permissions that are required on the tartget Content for the Application to be applicable to it. For example for an Edit Application one could specify the Edit permission to be required on the Content, so that for users that don't possess sufficient rights the Edit link will be disabled and thus cannot navigate to a Content's Edit Application. Besides the permissions specified here there are some necessary basic permission settings for a Content to be presented with an Application, see detailed info later in this chapter.
- DeepPermissionCheck: if set to true the required permissions specified above are checked for the entire subtree under the context Content. This can be a useful setting for Applications that operate on whole subtrees, not only specific Content (a subtree move or update Application for example).
- IncludeBackUrl: setting it false will guide the action presenter logic not to include a back url in the action url. Default value for the portal is True except for Browse actions. For more info see the Action page.
- CacheControl: the response is generated with the selected Cache-control headers. Its value can be one of the standard .NET values (NoCache, Private, Public, Server, ServerAndNoCache, ServerAndPrivate) or Nondefined (see Proxy Cache Configuration).
- MaxAge: it is an integer value in seconds for Cache-control: max-age=x header to be sent out (see Proxy Cache Configuration).
- CustomUrlParameters : this is a string value containing custom parameters that will be added to the action url that belongs to this application. E.g. 'type=visible;mode=m1'
For more information check Application Content Type.
For a Content to be handled by an Application, the user needs to have the following rights applied on the Content:
- RunApplication (only before version 6.3)
For an Application to handle any Content, the user needs to have the following rights applied on the Application:
Otherwise the response status will be 403 (and login screen will appear) or 404, depending on whether the user is granted the See permission or not.
If the user has no permissions for a particular application on a lower level (e.g. under a workspace), he may still invoke tha action (e.g. Edit) if he has permissions for the same application on a higher level (e.g. in the /Root/(apps) folder). For more info on application hierarchy, please check the Smart Application Model article.
In addition to all the above the Application itself may specify further required permissions on the Content (or subtree with the Content as root), which is controlled by RequiredPermissions and DeepPermissionCheck Fields (see Application configuration section above). Furthermore, depending on the Application page layout and composition some functions may not be available for some users: for example an Edit Content View placed on an Application page visible to all users will not display any Save buttons for users that do not possess Save permissions for the Content displayed.
Before version 6.3: Note that for a specific Content to be presented by a specific application users need to have RunApplication permission for both the Content and the application.