So far we have introduced only the basic concepts of the ContentServer layer. Basically it is the intepreter of the underlying web programming language of WCS.But WCS is an application, and his value is mostly there. Se we start now examining applications.
I prefer to distinguish the different underlying modules and use their internal name, because understanding which module we are talking about make easier understanding how the various modules interact. For example we will see that a Role cannot impact on ACL because the ACL belongs to the underlying layer.
Now, let's examine the first applicative layer built in ContentServer, Xcelerate.
Xcelerate is the internal original name of the CMS module (at some point in the history called also CS-Direct), and it is still available today, and is better known as the Advanced Interface. You can still see the Xcelerate name when you log directly into the WCS advanced interface using the URL
http://www.yoursite.com/cs/Xcelerate/LoginPage.html
Also you can see many elements named Xcelerate when you look at the ElementCatalog table.
In ContentServer we have only a concept of code. We have seen that code is actually stored as an attachment to a database table. I remember that a single piece of code, stored in a file and attached to a record in the ElementCatalog table is called Element. Basically, managing elements is the main job of ContentServer.
Xcelerate introduces a new concept, the Asset. Creating assets, managing them and providing a rich user interface for this purpose is instead the main job of Xcelerate.
What is an asset? In its simplest incarnation, an Asset can be thought as a single record in a database table. However it is not just this. Asset can be of different types, and each asset type has their own methods for editing. So basically for each asset there are associated forms to create and modify it.
It is important to understand that an asset is not limited to a single database table: it can actually store references to other tables. For example, the asset Template, since it allows to edit an element, is stored mainly in the Template table but it references (and allows editing) also record stored in the ElementCatalog and SiteCatalog tables. In a sense, Xcelerate provides also a user inferface for ContentServer through some specific assets.
WCS comes bundled with a number of predefined assets. Those assets are used to implement some standard WCS features.
As an example, let's consider the asset Page. This asset is used to build a the hierarchy of web pages in our web sites, and there is a standard feature, called the site plan, that renders this hierarchy. We will discuss of Pages and SitePlan in greater detail later. So far I used it only as an example of system asset. But before we move on, an important note:
A Page is NOT used to represent a single WebPage. I mean, it is wrong to assume (as many does) that you have to create a Page to render each asset as a Web Page. Page are actually used to model Sections in your site, not the complete site.
It is also immediately worth mentioning that ElementCatalog and SiteCatalog tables have a counterpart as an assets.
Basically a single entry in the ElementCatalog table can be created creating an asset CSElement, while an entry in the SiteCatalog table can be created with an asset SiteEntry. Please note that each asset has also its own table (and sometimes other additional side tables). So CSElement and SiteEntry are stored each each in 2 different tables (CSElement/ELementCatalog and SiteEntry/SiteCatalog).
We already mentioned the Template asset, that is also the more widely used asset when you build websites. This asset actually creates both an entry in the Template table but also it creates an entry in the ElementCatalog, and even one or more entries in the SiteCatalog table. So basically a template is stored at least in 3 tables: Template/ElementCatalog/SiteCatalog.
We mentioned also the Page asset, and while it is stored mainly in the table Page, but the hierarchy on pages is stored in a separate table called SitePlanTree.
So far so good providing examples that clarify there is not an one-to-one relationship between tables and assets.
Next step will be to examine custom asset defined in Xcelerate, the so called Basic Assets.
