Understanding XML Registry
Gathering all plugins contributions
One of the key concept of Pydio internals is that all active plugins are contributing a certain amount of information, directly declared from their manifest.xml or eventually programmatically built, and that information compose a big XML Document called the XML Registry. This registry is thus reflecting very precisely the state of the application (all active plugins), and can be queried using XPath to get such or such information.
Once you get this, you can even see the other way round : every XML node declared somewhere in the XML manifest files of the plugins are just fragments of a bigger document, the XML registry. This allows to merge XML branches that have the same parent node into one.
XML Merging example
For example, if one active plugin contains the node plugin/actions/action[name=’action1′] and another one contains the same kind of structure with [name=’action2′], both
<action> nodes will be merged under one unique
<actions> branch in the registry. Going further, if a third plugin contains a node plugin/actions/action[name=’action1′]/action_detail, this
<action_detail> subnode will be appended to the
<action name="actions1"> node declared by the first plugin inside the registry. Want to understand this better? Open some manifest.xml files that are inside plugins you are indeed using, then call content.php?get_action=get_xml_registry to see the big picture!
Importing external XML Nodes
Last thing need to use these XML files nearly as a language scripting is to be able to insert a given set of XML from another file into a Manifest. For example, the FTP plugin is using all the same actions as the FS plugin, so it would be useless to have to re-declare all actions definitions in the FTP plugin. The
<external_file> key is here to do the job : with an include/exclude mechanism that takes XPath expression as arguments, it allows you to import all the nodes returned by the include expression inside your current XML.
At this point, you might ask your self “how to be sure that one plugin will be loaded after another?” so that plugin B overrides plugin A data and not the opposite? The third leg of the plugin mechanism indeed resides in the “dependencies” mechanism, once again declared in the manifest.xml file. If a plugin B declares that it depends on plugin A, it will indeed be loaded (and integrated to the registry) after plugin A, or not loaded at all if plugin A is not present. This mechanism can play at load level and at activation level.
How the registry is changing in time
Now that you understand that the registry is built from the bunch of plugins contributions, you must understand how central it is in the way application, particularly the GUI. By nature, some plugins (namely the access.*, auth.* and serial.* ones) can have only one instance linked to a given state of the application. For example, even if auth.serial, auth.remote, auth.ldap, etc, are available plugins, only one can be active at a time in each category of plugin. Going further, the active plugin in this given category can dynamically change its own registry contributions, depending on the state of the current session!
<user> data is passed inside the registry? Now log out and update your registry :
<user> is out. It’s exactly the same when you are switching repository : the registry is totally rebuilt, given the registry_contributions of the active access.* plugin, which is determined by the current repository.
The GUI Ajax client itself is based on the XML Registry : since the XML registry is evolving in time during a session, it must be partially or totally reloaded by the client when some predefined events occur (login, logout, switch_repository, etc…). This allow also to pass GUI components configuration to the client via the registry, and they will be reparsed and reapplyed on-the-fly (if the target components allows it). See Ajax GUI > Updating components configurations.Back to top