The Telligent Evolution platform is the foundation for the Telligent Community 7 and Telligent Enterprise 4 products.
Are you looking for user documentation? Please visit our end-user documentation for Telligent Community 7 or Telligent Enterprise 4. If you are looking for 7.5 developer documentation, please see this wiki.
New features for developers in 7.0
- New functionality added to platform APIs.
- 50+ plugins now available for platform extensions.
- Core services:
- Adaption of Event modules (CSModules) to plugins.
- Evolution as an OAuth Provider.
The many roles of plugins in 7.0
Plugins were introduced in Telligent Evolution 6.0 and continue to serve as the basis for extending the platform in 7.0. They allow for functionality to be enabled and configured without modifying configuration files or continuously removing components from your site.
Plugins are used for exposing UI data, search, parts of authentication, and the new core service model. Plugins replace CSModules for handling system events.
Some notable plugins in 7.0
- Resource management for non-widget resources.
- In 6.0, widgets managed their own resources without relying on a centralized resource file. In 7.0, plugins adopt the same ability using ITranslatablePlugin.
- Because it is code-based, the plugin can also expose resources to other areas and across multiple plugins.
- The plugin is importable and exportable via the Control Panel.
- Allows custom content to be exposed to core services.
Serves as the basis for making Telligent Evolution recognize content - both internal and custom.
Allows content to utilize core services.
It's the fundamental building block for the content core service.
- Prohibits enabling plugins that have missing configuration.
- Allows only a single instance of that type to be enabled at a given time.
- Allows plugins to install dependent components while respecting version.
- Allows a developer to inject content directly into the <Head /> of a page, like script tags or includes.
- A plugin that behaves like a .NET HttpHandler without having to create a generic handler on the file system; add it to the config file or create a SiteUrl entry.
- Replaces the old file viewer implementation with a plugin-based interface. Legacy file viewers built against the previous model will work in 7.0.
- Offloads the definition of file storage to a plugin. File system-based filestores also will by default be assigned to a group that handles the default path.
Understanding content with plugins
Telligent Evolution recognizes content as a minimal set of information needed for it to function within core services.
- Information you want Evolution to recognize and allow to be interacted with.
- Categorizes content and identifies it to Evolution. It also provides the interface for retrieval of additional information from a secondary system.
- Content belongs to an application. For example, a blog post is content, and it belongs to a blog which is an application.
- Applications belong to containers. The most recognized content container is a Group.
Core services overview
All core services rely on the content core service, which persists the basic information needed to identify and interact with content. This information is obtained using the IContentType plugin and related interfaces.
Many core services can be categorized within themselves. For example, you can specify a comment type in the comment core service, allowing you to have different comment streams for a single piece of content.
All additional core services extend IContentType to gather additional information specific to that service. For example, ICommentableContentType is a plugin that extends IContentType, adding methods that allow permission checks.
New Core services were added to 7.0:
Certain core services can be consumed by external systems using REST and OAuth services for Evolution. External systems are still loaded into the content core service; however, a unique url is used to identify the content. This enables features like commenting, likes, and ratings to be applied to custom content outside of Evolution. In this scenario, external content belongs to an application defined in the new OAuth services for Evolution and permissions are granted to the application.
The third-party application is responsible for determining permissions at the user level.
Telligent Evolution becomes an OAuth provider based on the OAuth 2.0 specification. OAuth is designed to ultimately replace REST authentication by API key. It uses the concept of obtaining a token that expires to access Evolution resources either by request or direct grant. The provider utilizes three types of authentication:
- Authorization code: The client application sends the user to Telligent Evolution to sign in and a token passed is back to the client application.
- User credentials: Instead of redirecting to Telligent Evolution, the client application obtains user credentials and submits them for an access token.
- Client Credentials: Similar to the API key service account concept, this allows an application to impersonate any user.
Event-based plugins replace CSModules in 7.0. (CSModules continue to work in 7.0, however they continue to expose internal code and entities that are not upgrade-safe.) Event-based plugins use the same Pre(Before) and Post(After) pattern for events as CSModules. They are handled in any plugin and wired up during the plugin initialization(Initialize() method).
In the new event plugins, signatures for events are different and upgrade-safe. Each event has its own event argument that only exposes properties which can actually be manipulated.
More about Plugins.
In 7.0, search is no longer divided into different search and index providers. A single plugin defines the search provider and provides the interface to both execute a search and index documents. Search indexing is handled by a derived IContentType Plugin called ISearchableContentType that provides methods to provide content(internal and custom) to the search index.
A plugin is also provided to allow translatable categories for custom content.
Given a search content type of “custom”, you can define “custom” to display a resource that appears in the search results widget.
More about Search.
- Platform APIs continue to be backwards-compatible while being enhanced with new functionality.
- Plugin model continues to serve as the basis for extensibility.
- Upgrades from 6.0 should be straightforward, provided APIs were adopted and the new theming model was used.
- Sites that have fully converted to studio widgets, supported platform APIS, and configuration-based themes should have minimal, if any upgrade issues.
- The upgrade path to 7.0 is similar to 6.X with a few exceptions.
- File-based themes still work, but will mask beneficial functionality.
- Custom SQL may break due to Schema changes (5.x->6.x).
- Namespaces between 5.x and 6/7 are different.
- Code and file-based widgets still work.
- All V2 REST APIs and platform APIS are backward-compatible.
- Any obsolete methods will need to be changed if re-compilation is required.
- Exceptions specific to 7.0:
- In 6.0, V1 Web services worked but were obsolete and not supported. They are fully removed in 7.0.
- In 6.0, Chameleon server controls were obsoleted, and have been fully removed in 7.0.
- Remaining server control prefixes will be TEControl versus CSControl, however should still be avoided.
- Any custom search indexing and/or search providers will need to updated to the new search APIs as several search components are obsolete in 7.0.