Getting started - developing applications
This guide assumes you already have a basic knowledge of managing content and building portals in Sense/Net. If you are new to Sense/Net please read Getting started - using Sense/Net and Getting started - building portals before advancing. Also, you will find some relevant information on installing Sense/Net in the Getting started - installation and maintenance guide.
Developing against Sense/Net Content Repository
ASP.NET Webform portlets
How to create and install a Portlet - An itroduction about how to write your first Sense/Net portlet.
OData REST API - Accessing the Sense/Net Content Repository with a standardized RESTful API, namely OData. Sense/Net content and functionality is exposed via HTTP, so you can create any applications on a robust and performant content repository.
Most common API calls - You can check out the most common .Net API here.
Setting up your development environment
Most common API calls
The following article shows some common scenarios for which common API calls are used. The following scenarios are explained:
- User creation
- Adding users/groups into another group
- Creating a Workspace
- Adding a Folder
- Uploading a File
- Setting ACLs
- Checking permissions
- Searching workspaces
- CacheablePortlet: when using this class as the base class portlet output cacheing functionality will be included in your portlet and a Cache tab will appear on the portlet properties dialog.
- ContextBoundPortlet: inheriting from this class will allow you to reach context binding functionality from code using the ContextNode property and a Context binding tab will appear on the portlet properties dialog. Note that a ContextBoundPortlet is also a CacheablePortlet.
- ContentCollectionPortlet: this is a common portlet used to handle collections. Derive your portlet from this class to get some collection related functionality like the GetModel() function returning an object containing the current child collection. A Collection tab will appear on the portlet properties dialog where builders can define the current collection.
It is highly recommended to develop cacheable portlets all the time. Cacheing can be switched off on cacheable portlets any time, but the only way to make non-cacheable portlets cacheable is to rewrite them.
Implementing custom logic can be done just like implementing a custom ASP.Net Webpart. The following how-to shows how a simple portlet can be created from scratch:
Content and Node API
- Node: this is the storage layer for a Content. It is the parent type of all ContentHandlers, that define properties that are persisted to the database and implement custom storage-related logic. Use this class whenever you need to perform low-level operations on Content, like creating, moving, copying, deleting, etc.
- Content: this class is the presentational layer of Content and it is built above the Node layer. You can always initialize a Content from a Node. The main difference between the Node and the Content is that while the Node contains properties that are the low-level representation of data persisted to the database, the Content contains Fields that are built above the property data with extended logic. The upper presentational layers (ContentView) also rely on field logic so you should use the Content class whenever it has anything to do with presenting Content on a UI or accessing custom logic of Fields.
To understand more of the above concepts read the corresponding reference documentation:
Note, that the Node is an abstract class and the Content Type hierarchy is represented by derived types. The most basic Node is the GenericContent which is the ContentHandler of the GenericContent Content Type. There is some custom logic implemented on GenericContent so it is useful to get acquainted with this type when developing applications over the Content Repository:
Creating new Content can be done via either the Content or the Node API. You can create new Content by instantiating derived classes of Node (ie. User, Folder, File etc.) or using the Content.CreateNew static method. Also, you can create Content from templates. For the latter, the following documentation will be helpful:
Using ContentViews from code
You can read more about using the CommandButtons control and how to attach to CommandButtons' events here:
Creating custom Field ControlsField Controls. A Field Control is an ASP.Net UserControl that defined some methods for using within Content Views (ie. GetData(), SetData() methods for data transfer between the control and the content's Field). A Field Control can be used in templated mode meaning that the ASP.Net layout is defined either in a separate file under the folder /Root/Global/fieldcontroltemplates or in the Content View as an inline template. The following how-to shows you how to develop a FieldControl to present the value of a Content's Field in a custom way:
You can find examples for built-in FieldControls in the source under the folder Portal/UI/Controls/FieldControls. Read more about Field Controls here:
Creating custom Fields
The field's configuration and validation is handled by a FieldSetting object. In many cases it is desired to define custom field validation logic, for which implementing a new FieldSetting class can be a useful extensibility point:
Creating custom ContentHandlersContent Types! Read the following article to get acquainted with the various possibilities a custom ContentHandler allows you to exploit:
Also, the following tutorial might be helpful:
The above articles showed you how to implement logic to customize content operations on your type or create special properties. It is also possible to create a ContentHandler that handles url requests to the Content and generates custom response. For example you could create a Content Type for sitemap configurations, and when the sitemap configuration Content is requested in a browser, the ContentHandler for the type returns the sitemap with the given configuration in XML format - simply using the common IHttpHandler interface. This next tutorial shows you how it's done:
Creating and using custom user controls
As you've noticed in the above tutorial the created portlet became very simple since most of the application logic was implemented in the code-behind of the used ASCX file. This means that a single thin portlet could host your various applications. For this reason the system comes with a special portlet designed to host custom ASCX controls:
Using an ASCX also has the advantage that you can write inline code between the markup. This allows you to create simple applications containing only a couple of codelines and the markup within one single file. It is also possible to take advantage of some built-in Content-presentation features like paging and sorting within a single ASCX. The next tutorial shows you a good example for this:
Developing custom ActionsAction when you need to achieve any of the following:
- to create an action link for redirecting the page to a custom location
- to control the visibility of the action link from C# code
The following tutorial shows the tricks for implementing a custom Action:
For developers who want to create actions that are accessible through the OData API:
You can also create Applications like a simple Smart Page with advanced functionality controlling the response for the request. The next how-to shows an example for doing this:
Another aspect of extending the functionality of the Smart Application Model with programmed logic is creating custom Scenarios. You could already come accross the concept of Scenarios when displaying an action link on a content for a Smart Page. A scenario is basically a defined list of actions. There are some custom built-in scenarios that build up their lists using special logic: the New scenario for example collects the available Content Types in a given context and provides action links to create content of the available types. To build a custom action link list you can create your own scenario, just read the next tutorial to get into picture:
Tracing, logging, debuggingDebugView and read the following article:
You can easily create applications that log events and errors using the portal's logging framework. This next article let's you know everything about using the logging API and configuring logs:
Debugging your applications is done the same way you would do it with any ASP.Net application. Just run the portal on your localhost and attach your Visual Studio to the process of your web server! The following how-to helps you in debugging the portal's code if you need to understand underlying portal mechanisms:
Developing console applications
When you need configuration values that are essential during system startup, you can store them in the Web.config file. In all other cases the best practice is to use the Settings infrastructure that is available from Sense/Net 6.3. It handles caching and you can retrieve strongly typed values through a simple API.
Congratulations! You have finished the Getting started guide on developing applications under Sense/Net! You are now able to create portals fully customized to your needs. You can check out the How-tos page to see more tutorials or you can return to the Main Page and check out other Getting started guides to get acquainted with other areas of Sense/Net!