Contensive SMS Architectural Overview
The Contensive Server Framework (CSF) provides an environment for internet applications. Among it's goals are:
- Allow designers and UI/UX professionals to use their native tools to create and modify.
- Allow developers to easily attach to and update the design elements.
- Move as much of the site control and management to the content administrator as possible.
- Focus on application lifecycle support.
The framework is composed of four parts:
- The Hosting Page. The hosting page contains a short script, written in a script language like php or aspx. On each request (page hit) the hosting page creates an instance of the rendering client, sets the client's request context, calls the client's getDoc() method, and processes the results. This part of the application gives the developer flexibility to quickly addresses issues in the scripting environment. Generally there is only one hosting page needed for the site(s).
- The Rendering Client. The rendering client is an object created by the hosting language that converts requests from user clients (often browsers) into fully rendered responses (pages). All application traffic goes through the Rendering Client.
- The Server. The server acts as a persistant store and a task scheduling.
- The Background Processing Environment. Application tasks that can be run offline can be transferred to background processes. For example, the ecommerce addon includes background processing for periodic charges, invoicing, etc.
Pages are rendered using several primary components:
- Link Alias Record. Associates a URL's page name (everything to the right of the first slash) to a Page Record
- Page Record. Contains the content and settings for a page. Pages include a selection for Parent Page, the page immediately above it in the page hierarchy. Pages that have a Parent Page as said to be Child Pages of that Parent Page. A page without a Parent Page is called a Root page.
- Section Record. Contains the settings for each section in the site. Sections have a setting for their Root Page. When a user goes to a section, the Root Page is displayed.
- Domain Record. Determines the behavior for each domain.
- Template Record. Provides the html/css for a template.
- Addon Record. Provides references to all the resources necessary for custom functionality.
The rendering client creates the document as follows:
- If a Link Alias (user friendly URL) is requested, it is translated into a page Id and optional Querystring.
- If no page Id is set, the home page is used. The appropriate home page is determined from the domain in the URL.
- If the page referenced is not valid, a page-not-found pageId is used. The appropriate page-not-found page is determined by the domain in the URL.
- If the page does not reference a template, each page is checked up to the root page. If no page template is found, the section is checked. If no section template is set, the domain's default template is used. If the domain is not set, the "Default" template is used or created.
- If the template is not allowed on the current domain, a redirect occurs to the home page of the domain.
- When the page is rendered, any addons within the content may be rendered in place.
Section 2: Addon Overview
Addons can be configured to add to content (as drag-and-drop in the wysiwyg editor), or they can run automatically in several positions of every page, or they can run in the background periocially. They can also be referenced by other addons as a requirement. For instance, any feature you create that needs jQuery just has to check the box marking jQuery as a dependency. The system automatically adds it once and only once, in the correct order.
Section 3: The Application Development Environment
There are two primary parts of an application, the content structure and the addons. The content structure are the components you might consider as a normal dynamic website, pages, templates, etc. Addons execute the custom functionality. Content development will not be covered here.
Section 3: Tour a Site
Section 4: Understand the Page Rendering Archtecture
Section 5: Create an Addon
Section 6: Add a Dot Net Assembly to an Addon
To include the output from a dotnet assembly to an addon, build a compatible assembly, install it on the destination machine and add it's full name space plus class name to the DLL section of the addon. This is a quick description of how to do this.
You need Studio 2010, Visual Basic or C-sharp. 2012 should be fine but it is not tested yet.
Download the templates from:
Unzip the files. Eventually you might want to create a visual studio project template from these projects. For now just use them.
There are a few basic changes you will have to make:
- Add a reference to cpBase.dll, located in the Contensive program files folder.
- If the project is for a client, we set the namespace to the client name. If it is an internal addon (like the blog will be), we set the namespace to Contensive.Addons
- We we the class name to represent the functionality. For instance, if the addon will be the blog, we might call the class blogClass.
- Go to project properites and update the Post Build event so it copies all DLL files created to the Contensive\Addons folder. I will tell you why later. It will probably look like this...
- copy $(TargetDir)"*.dll" "C:\Program Files\kma\Contensive\Addons"
If your system is a 64-bit system, please update the destination to the \Program Files (x86)\ folder.
To test the addon, build this first. Then create an addon in the website. In the DLL tab, put addonTemplateCs.addonClass (or whatever you changed the namespace/class name to). Click on the addon and you should get "Hello World"
Addon assemblies only have one public method, execute( cp ). CP is the main API to the system. The assembly returns a string back to the system, which is the result of the addon.
There is a reference online at:
BE CAREFUL -- The argument passed to contensive assemblies, cp is an object from a class that inherits an abstract base class. What that means is that you will program assuming the object passed to you is cpBaseClass. ALL the doumentation is written about cpBaseClass and all the other base classes. In reality, the cp object is built from cpClass, but it is a subclass on cpBaseClass so all the cpbaseclass properties and methods are supported.
The cp object does not have properties or methods by itself, it has classes with properties and methods. So if you want to save a string to a file, you would us the cp.file.save()
Looking at the API page, on the left,
open Contensive Base Classes
You see everything in CPBaseClass are classes
One of the objects in CPBaseClass is the CPFileBaseClass. Go back to the left navigation and open the CPFileBaseClass section, and click on members. You see a list of methods, one of which is save()
To use this save method, you enter cp.file.save( "filename", "content to save" )
You should restrict your access to two locations:
cp.site.PhysicalFilePath - the file area your site stores files, located at \inetpub\sitename\files\
cp.site.PhysicalWWWpath - the root of the website, located at \inetpub\sitename\wwwroot\
Reads and writes will be restricted by the framework in future builds.