Controller SPI
We can use the Controller SPI for portal administration. It allows us to modify portal resources. It enhances the read-only portal Model SPI by adding writable aspects.
The interfaces of the programming model for portal resources that are published under the topic Model SPI overview offered only read-only methods. The Controller SPI extends them by adding has a set of new interfaces. These interfaces are derived from the read-only portal models and interfaces and map to them, but they also extend them with methods for modifying the resources that they represent. This way the Controller SPI allows us to modify portal resources to a certain extent.
Controller SPI overview
The Controller SPI provides controllers for portal resources. We can use these controllers to modify portal resources that are exposed by particular models of the Model SPI. Controllers offer methods to modify the topology and properties of the model and of its nodes. They expose the same interfaces as the corresponding read-only model, and they instantly reflect modifications that you apply to the controller.
While the modifications come into effect immediately for the controller, they not reflected in the persistence layer until you commit the controller and the changes that you made by it.
The resources that are exposed by the controller can be modified through specific interfaces which match their read-only counterparts. For an example, refer to the following class list:
Further benefits of the Controller SPI are as follows:
Classes from the read-only model . . . . . . are reflected in the Controller SPI by the following classes ContentNode
- MarkupCapable
- Localized
- Identifiable
- ActiveFlag
ModifiableContentNode
- ModifiableMarkupCapable
- ModifiableLocalized
- ModifiableIdentifiable
- ModifiableActiveFlag
- Controller instances work as workspaces where you make the modifications. We can try your modifications and assess them in a preview mode. When the changes meet the requirements, you apply them to the portal by a commit step.
- We can make and apply the changes to a running portal environment. You do not need to restart the portal for the changes to take effect.
The Controller SPI provides the following controllers:
- Content Model Controller
- This allows us to modify the content topology and the properties of content nodes such as pages, labels, and content URLs.
If you modify the content topology, this might also change the navigation of the portal for the users.
- Layout Model Controller
- This allows us to modify the layout of a page, such as the topology of layout elements of a page, and the properties of layout elements such as layout containers and layout controls.
- Portlet Model Controller
- This allows us to create, update and delete portlets.
At this time there is no controller for the following models:
- NavigationModel. This is by implication of the structure of the content model.
- NavigationSelectionModel. This is computed from the navigational state per request.
- LanguageList, MarkupList, SkinList, and ThemeList.
A controller is based on the corresponding read-only model. This means when you first create the controller on the basis of a read-only model, both the controller and the model expose the same information. We can then use the controller to create, update, or delete information exposed through it. These changes will be reflected in the controller immediately. To persist changes that you made to the underlying read-only model, you need to commit the controller.
In particular, a controller offers methods to do all of the following:
- Provide modifiable instances of existing resources. These modifiable instances exist for each modifiable resource property, and they allow for these properties to be modified.
- Create and delete model resources.
- Obtain dependent controllers. This is optional.
For example, a ContentModelController offers a method to obtain a LayoutModelController.
- Persist the modifications.
Before we use the Controller SPI, be sure to familiarize yourself with the read-only models. Refer to Model SPI overview.
Scope of the Controller SPI
A controller instance is based on a read-only model instance. Therefore it has the same scope and lifetime as the corresponding read-only model. Consequently, the following equivalences apply:
- If the underlying model is scoped to a particular user, then so is the controller.
- If the underlying model is scoped to a request, then so is the controller.
- If the underlying model is scoped to a virtual portal, then so is the controller.
- Packages of the Controller SPI
The portal provides the SPI Controller in several separate packages.- Work with controllers
When you modify a portal resource with the Controller SPI, you go through has a set of steps.- Making modifications using the Controller SPI
The Controller SPI allows us to modify portal resources, the topology of the portal, and properties.- Confirming modifications
Modifiable interfaces and Controller interfaces provide methods for confirming modifications. We can use these confirm methods to check whether modifications might be prevented by portal internal constraints.- Tips for using the Controller SPI
These are some hints and tips for using the Controller SPI.
Parent: Develop portlets
Related:
Model SPI overview
Related: