An element or subsite in a RIFE application can inherit another element. From now on, we'll call the element that inherits "child", and the one that is inherited "parent". The way inheritance works is that under certain circumstances, the processElement method of the parent will be invoked instead of the child one.

RIFE handles this in a very smart way and makes this process completely invisible to the child element. The parent element can be part of a full-blown site structure. It can activate exits, accept and process submissions, go to other elements that use inheritance too, ... Every single feature of RIFE's web engine is at your disposal in the parent. You're even able to inherit from an entire isolated subsite if it has an arrival element! Once you'll give the command to break out of the inheritance, the child is activated and receives exactly the parameter values that it was supposed to receive in the first place.

In our case, we will make the admin site inherit the authentication element. When the user is not logged in, the parent element will be displayed, and otherwise the child, that is the admin site, will be displayed.

The RIFE engine determines which of the parent and child to use through something called a "childtrigger". We mentioned child triggers very briefly in Example 8.5, “The authentication element”, the authentication element. The childtrigger tag in the parent element specifies the name of a variable or cookie to use for determining which element to run. If the trigger is not set, the parent's processElement method is called directly. If it is set, the method childTriggered of the parent element is called, where we can check if the value of the trigger is valid or not.

This might sound a bit complicated, but fortunately all of it is implemented in the memory users authentication element that we extended, so we don't need to handle it. It's still useful to know what happens behind the scenes, and for a more advanced application it might be necessary to implement a custom element that handles child triggers.

The child trigger in our authentication element in Example 8.5, “The authentication element” is a variable called authid. We'll add it as a global variable to the site definition in sites/friends.xml to make it available from the elements:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE site SYSTEM "/dtd/site.dtd">
 
<site>

  <!-- Add authid variable --> 
  <globalvar name="authid"/>
  
  ...

</site>

Now we're all set for the last step, making the administration subsite inherit the authentication element.

We still haven't made any changes to the original friends application, except for splitting it up in a main site and an administration subsite. As a matter of fact, that is the beauty of using inheritance: there is no need to rewrite or add to the element or subsite that is to become the child. All we need to do is to modify the subsite definition in sites/friends.xml:

<subsite id="ADMIN" file="admin.xml" urlprefix="/admin" inherits="AUTH"/>

After adding the property inherits="AUTH", the admin site will be password protected, with no other changes required.