Keyvan Nayyeri

Those who use Telligent products like Community Server or Graffiti CMS, would been able to notice a change in the way that Telligent has improved usability of its products and has made the configuration easier via user interface rather than XML configuration files.

Prior to Community Server 2008, you had to use XML manipulation operations in order to fetch data and work with them in API. With the birth of Graffiti CMS, you can see that everything is configurable via the user interface and a developer can use API to build such a simple way to configure his plug-ins or widgets. Moreover, in Community Server 2008 you have same capability in widgets or spam rules and some other parts that have made things pretty simpler and nicer.

But how these things are achieved? In 2008 Telligent has introduced a new feature in its products that is called Telligent Dynamic Configuration. As you know, Telligent doesn't provide source code for some parts of Community Server and normally these parts are placed in assemblies with a Telligent prefix in their name. Dynamic Configuration is also located in Telligent.DynamicConfiguration assembly which is available both in Graffiti CMS and Community Server 2008.

The idea behind Dynamic Configuration is simple: working with XML data to configure an application is a little hard even for a developer and it can be worse for a non-developer guy. But thank to the growing number of features to support XML in databases, nowadays we're able to store XML data in databases and retrieve and manipulate them easily.

So here we can use an excellent technique to define a simple framework with some API to store configuration data in pre-defined XML format or pure string and retrieve and manipulate them. Here we give simple programming API to our developers to use in their code rather than forcing them to work with XML directly.

This feature is helpful in three ways:

• It improves the usability and maintainability of an application. Of course, it provides and integrated mechanism among the core software and its extensions.
• It makes the development of the core product, extensions or add-ons pretty easier and faster.
• It makes the debugging of the code much easier and simpler.

This encapsulation is nice and hides the underlying API from end developer and user.

If you haven't gotten the idea yet, I can simply refer you to Graffiti_ObjectStore table in Graffiti CMS database where some rows are stored to keep XML configuration and settings for Graffiti plug-ins and widgets. Note that they're not limited to these two types of extensions because many other built-in features that require a dynamic configuration, apply this feature and have some data in this table, too.

In Community Server 2008, you can open cs_AddonConfigurationData table to see that such dynamic configuration data are stored as string values via property names and property values in the table.

In a nutshell, Dynamic Configuration applies XML serialization and deserialization or regular expression and string manipulations in its core to store and restore data into or from database. In an upper level it provides two types of API:

• API to store data from all different types like integer, string, Boolean, GUID or binary.
• API to restore data from database in different types (same types as above).

This is the main part of Dynamic Configuration which is actually a set of APIs for different data types to store them in different data storage systems or restore them later.

But the question is how can you bind this framework to the user interface? The answer is, this is left to you or Telligent team developers, actually. One time forever, someone should implemented some pre-defined common user interface elements to let others use them in the user interface. Telligent has done this and has provided an integrated user interface with its products.

For example, in Graffiti this is implemented as an abstract base class called FormElement and some common user interface elements are derived and implemented as a built-in part of Graffiti like TextFormElement or TextAreaFormElement. There is also an extensibility option to write your own elements by deriving from FormElement base class that I hopefully will cover in the future.

In a future post I want to step in more technical details about Telligent Dynamic Configuration and how to use its API to store and retrieve data both in Community Server 2008 and Graffiti CMS.

+ By the way, I want to return to some regular stuff about Community Server API with a special and initial focus on the major changes in 2008 and want to cover some commonalities between Community Server and Graffiti that would improve in the future versions to achieve some kind of integration. But I'm not going to use CS Dev Guide as a name anymore. I hope that this can reactivate Community Server development community a bit.