SenseNet Structure
From Sense/Net 6.0 Wiki
Contents |
[edit] Basic structure
[edit] Storage
Roles of the storage layer are the following:
- Hide the database implementation from the layers above
- Versioning support
- Security calls implemented at this level
- Providing the abstract Node class for the layers above to use
- Dynamic property binding support
- Node Query support
The Storage layer was designed to work on top of a relational database. However the bottom database layer could be switched to any other type of medium e.g. a text file by modifying this layer.
The layer implements basic security, versioning and caching related operations. It defines the Node class that takes uses the capabilities mentioned before however is defined abstract. The reason for the Node class being abstract is that the Storage layer is designed to be fully reusable and therefore it does not define a concrete minimalistic implementation of a Node. It only provides the infrastructure that classes inheritingfrom the Node can use.
Dynamic property binding is implemented at this level meaning that Node properies are mapped to slots (fields) in the database. Implementation of Node Queries are carried out in the Storage layer as well.
[edit] Content Repository
Roles of the Content Repository are the following:
- Implement the Content Type and Content object
- Implement basic Content Fields and Field Settings
- Implement a generic content type (GenericContent) with access to its properties in a generic way
- Provide basic object types for the layers on top (e.g. File, Folder, User, Group)
- Support defining and managing content types runtime
- Policy support: assign policies to users and groups
- Versioning implementation
- Localization
- Lister implementation
The Content Repository layer implements a specific storage type utilizing services in the Storage layer. Its most important role providing an interface through which contents can be defined. At this layer Nodes are wrapped into Content objects, each Content having a specific type and a list of Fields.
This layer specifies a generic content type, the GenericContent. Content Types having the GenericContent class set as their handler class need not take care of mapping their properties to database slots as the GenericContent class takes care of this. It also defines specific objects needed for most applications to work (e.g. files, images , folders, smartfolders, users, groups, domains etc).
Policy management and versioning are also implemented at this layer, as well as localization and the Lister content type.
You might also want to read How data is stored in the Content Repository
[edit] Portal Infrasructure
The Portal Infrastructure layer provides an infrastructure on top of which a portal can be built.
Roles of the Portal infrastructure layer are:
- Define portal related content types (e.g. Page, Site, PageTemplate etc)
- Portlet framework implementation - an extension to ASP.NET Webparts
- Content Views - support for visualizing contents
- Field Controls - support for displaying and saving fields of a content
[edit] Services
The Services layer provides different service APIs for other applications to build on. As of now it provides basic CMIS and WebDav support as well as some RESTful API calls.
[edit] Content Explorer
The Content Explorer is the backend administration tool for the portal. Main features of it are:
- Managing contents
- Managing security, groups and users
- Managing Page Templates and Content Views
- Managing Content Types
- Administering content
The only thing that cannot be done in the Content Explorer regarding site administration is visually editing pages and dynamically placing portlets on them.
The Content Explorer is a lightweight, Ext-based AJAX application that mainly uses REST calls of the Services layer to operate.
[edit] Core Portlets
Portlets are building blocks of a page - they can be simple or more complex web parts. They fully utilize the portlet infrastructure in the Portlet Infrastructure layer. Some examples of core portlets are:
See the complete list of portlets for the list of all core portlets.
[edit] Entry points for extensions
Sense/Net 6.0 was designed to have well specified entry points for devloping custom business logic or applications as well as for extending the system itself. On this extended structure diagram these entry points are marked with light blue:
Click for larger diagram: 
[edit] 3rd Party Database Providers
The Storage layer was designed to be built on top of a relational database. However it could be rewrited to work with any other type of data storage. If your goal is to port the system to another kind of storage than supported (as of now only MSSQL is supported) then you can do this by changing data access methods in this layer.
[edit] 3rd Party Content Handlers
The Content Repository layer has numerous of built in content types with related Content Handlers built in. Some examples include File, Folder, SmartFolder, User, group etc.
If your application needs other types of objects than the built in ones and you need to encapsulate custom business logic in them you should consider creating a content handler.
A Content Handler is basically a class instancing contents stored in the Content Repository. They can also reference properties that are either calculated or not stored in the Content Repository. Content Handlers may also contain custom application logic. For more information on Content Handlers and when you should create them see the What is a Content Handler? article.
[edit] 3rd Party Fields and Field Settings
The Portal Infrastructure layer defines a number of Fields and related validation logic in Field Settings (see the list of fields for details). However there may be special cases when the built in field types do not suit your needs.
If you would need another kind of data type (e.g. a data type supporting dates all the way until 4000 B.C. which the DateTime type does not) you can implement your own Field type.
If you want to create custom validation logic for an existing or newly created Field you should create a new Field Setting and bind it to the Field via the handler attribute in the CTD.
[edit] 3rd Party Web Services
You can build custom web services above the Content Repository to create a custom interface for your remote or lightweight applications.
[edit] 3rd Party Applications
You can build custom applications on the Content Repository that use the Repository as a data source. These applications can be console applications, MVC applications or any other kind.
[edit] 3rd Party Portlets
Portlets are a powerful way of encapsulating business logic for your application. If the portlets found in the Core Portlets layer do not fit your needs you can implement your own, see the How to create a Portlet? on getting started.
