This chapter explains how to add configurability to the friends application. As an example we will make the title of the display page configurable. This can be useful if there are several different people that use the same application, and they want the title to be, for example, "Friends of Mikael" instead of "My friends".
Configuration is handled by a participant named ParticipantConfig. We have already seen ParticipantSite but only talked very briefly about participants, so we'll take the opportunity to explain a bit more about what participants are and how they work.
A participant is a part of an application that handles a certain task. Simple applications might not use any other participants than ParticipantSite, but as the complexity grows, participants might be needed. Sometimes it might even be necessary to develop custom participants, in addition to the ones available within RIFE.
There are several built-in participants in RIFE for handling various tasks, and in this chapter we are going to take a closer look at the one for handling configuration. In the next chapter we will use the datasources participant, but for a complete list of built-in participants in RIFE, please look at the API documentation for the package com.uwyn.rife.rep.participants.
The participants are started in the order they are listed in the repository definition file. Each participant is launched in its own thread and they will therefore all execute simultaneously. In case this behavior isn't desired, it can be changed by adding the attribute blocking="true" to the participant tag. For example, if we want to be sure that the config participant has started before trying to start the site we would change the above ParticipantConfig definition to:
<participant param="rep/config.xml" blocking="true">ParticipantConfig</participant>
RIFE participants also have built-in dependencies. This means that if a certain participant depends on information that is provided by another participant, RIFE will block the thread of the dependent participant until the required participant is fully initialized. For most cases you thus don't have to handle the execution order manually.