Additional entities / legacy
The concept of service definitions are that the service defined will be able to deliver some sort of information through a binding for example. This is to separate the platform from the data sources in a generic way. We use the same concept to fetch information from InfoGlue which is why two default services are defined, one for content and one for structure.
We will not describe more of this functionality here as extending this part is described in the developer documentation in detail. The functionality is a great feature when it comes to integrating more data-sources.
Available Service Bindings
The available service binding concept is worth to mention although it is more defined in the developer documentation. In 1.3 and forward this feature is not used as much as people are now using components instead with the bindings they have but this is a similar feature on page level. The idea is to define which bindings are available globally to a page in the system. A binding is a possibility to integrate some sort of information from some sort of data source. The data source is connected by assigning a service definition. Each available service binding also has an interface which is what presents the user with a binding view. The interface is defined by an action.
The interface for creating new bindings is as follows:
When the available service binding is defined you must also go into the “Site Node Type Definition” menu and assign the new binding to the right types. When assigned to a page type all pages based on that type will have that binding available.
As we do not encourage people to use this feature very any more this section is very low on information. If needed - more information can be sought in the developer lists.
Site Node Type Definitions
The concept of a Site Node Type Definition is very important for developers to grasp it they wish to extend the platform in a fundamental way. It is described more in the developer documentation but the basic idea is that a page type can be much customized. A developer can implement his very own invoker which can be anything. It does not even have to deliver a webpage if that is the desired behavior. Examples of invokers might be A WAP-visualizer, a redirect node, a print-page or something very different.
The interface looks like this for a chosen item:
The field Invoker Class Name is what let’s the user define his own class. If not defined, the usual HTML-renderer is used. Below the input fields is the list of what bindings should be available on this node type. Mark those you wish to make available on pages of that type. Which bindings you need depends a lot on what templates you want to use.