Aikau introduced the concept of services which are helper widgets that perform commonly repeated tasks like communicating with the repo or displaying dialogs. Up until now, it was sometimes confusing as to which services you should include, and where you should include them. Extending a component required you to find out what other services were already on the page and making sure you didn’t include ones that were already included. That changed in a recent Aikau release (1.0.32): we now have a service registry which automatically prevents duplicate services from instantiating themselves.
Example of the potential problem:
Lets look at a specific example of the potential for issues using the Records Management (RM) module. In RM we use Aikau to add additional functionality to several pages, including the Document Details page. That additional functionality requires the use of the DialogService. In Alfresco One 5.0.1, the DialogService was not present on the standard Document Details page, so our extension added it in. However changes were made during the work on 5.0.2 which added the DialogService into the Share Header. What this meant was that when we installed the RM module on 5.0.2 we ended up with the DialogService being loaded twice on the Document Details page. That caused a few problems - mainly the fact that every time we requested a dialog we’d get two dialogs displayed. If you’ve got an Aikau extension that uses the DialogService, you’re likely to see the same issue when you upgrade to 5.0.2.
Possible Solutions (pre-1.0.32):
One solution for this - which we’ve used elsewhere - was to use the service-filtering.lib.js to filter the lists of services to include, but that approach requires extra work for extension authors and breaks down completely when you start combining extensions as it would require extensions to be aware of services added by other extensions. This approach has now been deprecated.
Another potential solution was to specify a scope for services added by extensions. Scoping services is not necessarily a bad idea, and in some cases can make sense, but forcing every developer to do that by default on their extension sidesteps a lot of the benefits of having a core service on the page that can be used by everyone, so isn’t the route we wanted to recommend you take.
Service Registry (1.0.32 and later):
The solution we’ve now settled on involves the use of a central registry so that Aikau knows which services have already been registered and the scope they’ve been registered against (by design most services use the global scope). All core services now extend a newly created BaseService widget which checks the registry during instantiation and will only set up topic listeners if there is not already an instance of that service registered on that scope.
If you have debug logging turned on, you will see some info messages letting you know when duplicate services have been detected and effectively ignored - these info messages can be safely ignored in almost all cases.
This service registry was released in Aikau 1.0.32 and is completely transparent to anyone using the core Aikau services - it’s always on and it works out of the box. There are a few things to note:
- If you’re writing an extension that uses services, include all required services everywhere and let Aikau do the de-duplication, this will protect you against service additions or removals from other components.
- If you’ve previously used service-filtering.lib.js to work around this issue, that approach has been deprecated and can be safely removed if you’re using Aikau version 1.0.32 or later.
We hope this change will make it easier for you to know which services to include and when to include them - but please let us know in the comments box below, or any of the other usual places if you’ve got any questions or comments about this feature.