Difference between revisions of "Considerations on porting Tab Plugins to Client-Server mode"

From Protege Wiki
Jump to: navigation, search
Line 1: Line 1:
 
In some cases a tab plugin will require some modification in order to function properly in client-server mode.  For example, consider the change tab plugin.
 
In some cases a tab plugin will require some modification in order to function properly in client-server mode.  For example, consider the change tab plugin.
 
This plugin monitors changes made to an ontology and displays a summary  of the changes in a nice way to the user.  When we first tried to run this  
 
This plugin monitors changes made to an ontology and displays a summary  of the changes in a nice way to the user.  When we first tried to run this  
plugin in client-server mode we  found that it did not function correclty.  The listeners that monitored the ontology for changes ran on each of the clients.   
+
plugin in client-server mode we  found that it did not function correclty.  The knowledge base listeners that monitored the ontology for changes ran on each of the clients.   
When one client made a change to the ontology, events representing that change were generated on each of the clients.  The listeners monitoring these changes fired on each of the clients and therefore more than one copy of each change would find its way into the changes tab.
+
When one client made a change to the ontology, events representing that change were generated on each of the clients.  The knowledge base listeners monitoring these changes fired on each of the clients and therefore more than one copy of each change would find its way into the changes tab.
  
The solution is to refactor the plugin so that the listeners run on the server rather than on the client.  Since there is only one listener on the servver the changes only get copied into the changes tab once.  In order to do this the tab plugin needs to be refactored into a combination of  the tab  plugin and the
+
The solution is to refactor the plugin so that the listeners run on the server rather than on the client.  Since there is only copy of each knowledge base listener on the server the changes only get copied into the changes tab once.  In order to do this the tab plugin needs to be refactored into a combination of  a tab plugin and a project plugin.  The
 +
project plugin is responsible for installing the knowledge base listeners used by the tab plugin.  in the standalone mode this approach works in exactly the same way that it did with the previous design. In the client-server case, the project plugin will be written in such a way that it will  not install the knowledge base plugins on the client side.  Only one copy of each knowledge base plugin will be installed on the server side.
  
 
[[Image:PortingTabPluginsToMultiUser01.png]]
 
[[Image:PortingTabPluginsToMultiUser01.png]]
 +
 +
In order to do this there is a small bit of magic code that needs to be  put iin place in the project plugin.  In the afterLoad(Project) code,  the project plugin will install the knowledge base listeners needed by the tab plugin.  This code should only be run when Protege is in standalone mode or on the server side of a client-server setup.  Therefore the afterLoad(Project) code must  check if it is on the client side of a client-server configuration and exit in that case.  In addition, by default the Protege server does not dispatch events  to the knowledge base listeners.  So the afterLoad(Project) code must  request  event dispatch by invoking the  call ''ServerFrameStore.requestEventDispatch(kb)''.
 +
 +
    public void afterLoad(Project p) {
 +
        KnowledgeBase kb = p.getKnowledgeBase();
 +
        if (p.isMultiUserClient()) {
 +
            return;
 +
        }
 +
        if (p.isMultiUserServer()) {
 +
            ServerFrameStore.requestEventDispatch(kb);
 +
        }
 +
        ''Install Listeners''
 +
    }
 +
    public void beforeClose(Project p) {
 +
        if ((kb == null ) || p.isMultiUserClient()) {
 +
            return;
 +
        }
 +
        ''Remember to uninstall listeners''
 +
    }

Revision as of 21:48, October 6, 2007

In some cases a tab plugin will require some modification in order to function properly in client-server mode. For example, consider the change tab plugin. This plugin monitors changes made to an ontology and displays a summary of the changes in a nice way to the user. When we first tried to run this plugin in client-server mode we found that it did not function correclty. The knowledge base listeners that monitored the ontology for changes ran on each of the clients. When one client made a change to the ontology, events representing that change were generated on each of the clients. The knowledge base listeners monitoring these changes fired on each of the clients and therefore more than one copy of each change would find its way into the changes tab.

The solution is to refactor the plugin so that the listeners run on the server rather than on the client. Since there is only copy of each knowledge base listener on the server the changes only get copied into the changes tab once. In order to do this the tab plugin needs to be refactored into a combination of a tab plugin and a project plugin. The project plugin is responsible for installing the knowledge base listeners used by the tab plugin. in the standalone mode this approach works in exactly the same way that it did with the previous design. In the client-server case, the project plugin will be written in such a way that it will not install the knowledge base plugins on the client side. Only one copy of each knowledge base plugin will be installed on the server side.

PortingTabPluginsToMultiUser01.png

In order to do this there is a small bit of magic code that needs to be put iin place in the project plugin. In the afterLoad(Project) code, the project plugin will install the knowledge base listeners needed by the tab plugin. This code should only be run when Protege is in standalone mode or on the server side of a client-server setup. Therefore the afterLoad(Project) code must check if it is on the client side of a client-server configuration and exit in that case. In addition, by default the Protege server does not dispatch events to the knowledge base listeners. So the afterLoad(Project) code must request event dispatch by invoking the call ServerFrameStore.requestEventDispatch(kb).

   public void afterLoad(Project p) {
       KnowledgeBase kb = p.getKnowledgeBase();
       if (p.isMultiUserClient()) {
           return;
       }
       if (p.isMultiUserServer()) {
           ServerFrameStore.requestEventDispatch(kb);
       }
       Install Listeners
   }
   public void beforeClose(Project p) {
       if ((kb == null ) || p.isMultiUserClient()) {
           return;
       }
       Remember to uninstall listeners
   }