Client Interfaces 

If a client package wishes to allow access to its own content and the content of its subpackages to a particular service, it can set up a client interface that refers to the service's corresponding access object.

A client interface can be created for each access object that is exposed in any package interface that is visible for the client package. It is not necessary (at least for setting up the client interface) to have the respective package interface usable for the client package.

Note: If the client interface is transported to a system in which the access object is not visible for the client package, the client interface will be kept, but will have no effect.

The interface that exposes the access object only needs to be visible so that a client interface can be created. This means that the superpackage (through its dependency control lists) cannot control for which services client interfaces can be created. However, in this way, editors can be excluded in the dependency control lists – editors that are required solely for processing the respective package content, but are never used directly from the package. Conversely, a direct use (for example, through calling a function module or a method) of an interface that exposes an access object, can be controlled through the respective dependency control lists.

Through a client interface, a client package can allow access to objects that stem from the client package itself, as well as to any objects that are usable for the client package. An object that stems from a package other than the client package does not need to be “marked as propagatable” at its original interface.

For composite objects, the corresponding component objects are exposed implicitly, that is, they do not need to be exposed explicitly. This is valid even if the composite object has never been exposed at a package interface.

Not exposing component objects at client interfaces is different to exposing composite objects at package interfaces. This is justified because, at package interfaces, a certain guarantee for the package interface's stability is given. By exposing component objects, it is made explicit that also these component objects are subject to this stability guarantee. However, there is no such stability guarantee for client interfaces - so explicitly exposing component objects is not required.

In particular to conveniently enable access by editors to a whole package hierarchy, client interfaces can be transferred to subpackages. In this case, of course, only those parts of the client interface can be inherited by the subpackages that are still valid in the context of the respective subpackage. This means that, for example, local program objects and objects which are usable only by the original package but not by its subpackages, are not inherited.

A client interface can be limited in its effect to the package according to which it is defined. Otherwise it will be effective also for direct and indirect subpackages for those types of access that make sense in the context of the direct and indirect subpackages.

When subpackages do not inherit their superpackage's client interfaces (for example, because they want to protect themselves against editing), the following rules apply:

·        Subpackages can define which current client interfaces of the superpackage apply for them and can refuse to inherit further client interfaces from their superpackage. In this manner, certain subpackages can exclude themselves from being edited, even if a new client interface (for example, for a new editor) is created in a superpackage at later time.

·        Subpackages can create their own client interfaces for services for which the superpackage has already created a client interface. If they only wish to add further objects to the objects defined in the super¬package, they can re-use the content of the client interface of the superpackage by entering a special pseudo entry in the interface. Otherwise, the settings of the superpackage will be replaced.