When a component is pasted into a form (or report), Rekall makes a complete copy of the component, with the exception of applying any configuration settings (for instance, the text in the stock navigation buttons).
If you subsequently make a change to the component itself, then this is not reflected in the form into which it is pasted. This is just the same as if you copy text from document A to document B, then make a change to document B; document A does not change. In the case of the stock components, which you cannot ( At least, on Linux not without changing user to the user under which Rekall was installed, probably root. ) change, but in the case of components that you have designed yourself, this might want to change the component and have that change reflected in the form. To do this, instead of pasting the component, you should link it.
Component linking is achieved by selecting Link component rather than Paste component. The component dialog is exactly the same, except that the stock (and local) components are not shown. This is because component linking only works with components that are stored in a database (or under the !Files server). A typical component dialog is shown below:
When a component is linked, Rekall inserts into the form the name of the linked component and the configuration settings. The configuration settings are stored as a set of overrides (see below). If the user changes the configuration value defined in the component then the override is marked as enabled, otherwise disabled. When the form is executed, the component definition is loaded and the enabled override settings are applied (where an override is disabled, then the value in the component is used). Note that this means that the form might fail to execute if you have changed the component in a way that is incompatble with the way it is used.
You can change the override values at any time by displaying the properties dialog for the component (in the form) and finding the Override entry. This is shown below:
Each override is displayed with its path name (which locates the object in the component to which it applies), the property of that object, the value to use and whether the override is enabled or not. In this example, the myname/mybutton font configuration, the myname/mylabel text and the myname/mylabel background colour overrides are enabled, the remainder are disabled.
The Edit button can be clicked to edit a property (or double-click the property). The Save and Cancel buttons are enabled when editing a property; the remaining button toggles the enabled/disabled state. Depending on the property, editing will either bring up a popup dialog (for instance for fonts and colours) or will overlay the override list.
So, why would you use a linked componenet? Suppose that you are implementing a Rekall front end to a database which has a large number of forms. All forms are to display a table column called amended, which contains the time and date at which each record was amended. You are asked to make the field that displays the value read-only (so that users cannot change it directly), and to show it with blue text on a grey background. This is an ideal situation in which to design and use a component.
Now, imagine one day the boss arrives and says that the management group have asked for the text to be changed to italic green-on-white. If you linked the component you need only change the componenent definition, which is just a few moments work (even if you tell the boss that it will take some time ....). And when he comes back later and says that the management group have decided that green-on-white is a mistake and that it should go back to blue-on-grey, you can feel comfortably smug about it!
You create components for linking in exactly the same way as with pasting. Indeed, there are no differences at all in terms of the design. The only difference in behaviour (apart from the fact that altering a component affects forms that link it, but not those into which it was pasted) is related to event functions.
Overriding EventsFor most attributes, an enabled override simply updates the property of the object to which it refers. However, in the case of events the situation is a little different.
If you override an object event in a linked component - for instance the onClick event of a button in the component - with a different script, then Rekall behaves as if the override event code has replaced the event code in the component. However, this is not really the case. In reality, the component event code is still there and can be accessed from the link event code. This is illustrated in the code below:
def eventFunc (button) : RekallMain.messageBox('In the override code') button.super() |
This code is the override code for the onClick event of a button. It displays a message saying it has been called. Then, the onClick event code for the button in the linked component is accessed via the button.super() (where super is short for superclass) call. This invokes the component event function in the normal way. Note, though, that if you invoke a component event function which expects other arguments (for instance, a block onCurrent event which is expecting the query row number) then you must pass these extra values yourself.
Anyone who has experience of object oriented programming may see that what Rekall provides here is an class/object model. The component is aa class; linking the component creates an instance of the class; and the user of the object (the form) can override properties and methods (the events). Since there is nothing to stop one component linking another component, it is possible to create class hierarchies (and, if a component links more than one other component there is something like multiple inheritance).