Powerloom GUI

GUI client for the Powerloom Knowledge Representation and Reasoning System.

See:
Description

Packages

edu.isi.powerloom.gui.common	Classes and interfaces used throughout the entire application, such as utility classes.
edu.isi.powerloom.gui.components	Swing-based GUI components and associated helper classes.
edu.isi.powerloom.gui.parser	A backtracking predictive parser.
edu.isi.powerloom.gui.plgui	Contains the protocol handler for URLs using the plgui protocol.
edu.isi.powerloom.gui.serverinterface	Utilities for communicating with powerloom and caching data.
edu.isi.powerloom.gui.xmlobject	"Value Object" classes used for holding data used by the application.

GUI client for the Powerloom Knowledge Representation and Reasoning System.

Coding Conventions, Techniques, Patterns and Frameworks

• Frames and Panels -Internal frames such as editors normally contain the high-level public API that the rest of the application uses to get/set frame data. For example, the concept editor ConceptFrame contains the method setConcept which is responsible for initializing the editor with a PLConcept's data. If a frame is sufficiently complex, it may have an associated panel which manages the internal frame components. For example, ConceptFrame has an associated ConceptPanel. All Internal Frames should inherit from PLFrame. This base class provides services such as edit listener management, window list management, clipboard management, open/close actions, positioning, etc.
• Cut & paste framework - The cut/copy/delete/paste framework consists of the classes DataTransferInfo, DataTransferManager, DataTransferRecord, PLClipboardOwner, PLClipboardOwnerParent, PLClipboardOwnerSupport, PLClipboardOwnerTable, and PLClipboardRecord. See these classes for more details.
• Adding a new internal frame - To add a new interal frame, you must first design the GUI. You can use a GUI editor such as Forte to create the layout for the internal components of the frame. Be sure that the frame subclasses PLFrame. Then add code for the component actions and GUI logic, and if necessary, add code in PowerloomApp for a menu item to open the frame.
• GUI updates -Components which modify the KB, such as the Concept Editor should fire a PLEditEvent event, filling in appropriate event fields such as the type of edit that was performed. Components which are interested in receiving updates when edits occur (such as PowerloomTrees) should implement a performEdit method, which contains code to update the display. For an example of firing an edit event, see ConceptFrame.commitMethod(). For an example of performing GUI updates after an edit event has been fired, see PowerloomTrees.performEdit().
• Value Objects - Objects which hold data (aka Value Objects) such as concepts, relations, etc. should be instantiated from classes that extend XMLObject. These objects are capable of being marshaled and unmarshaled to and from XML via the Castor framework. This facilitates client/webservice communication via SOAP or other XML-based protocols.
• Data access layer - The GUI client communicates with Powerloom via a Data Access Layer. This layer is responsible for communicating with Powerloom and caching data. The data access layer consists of the KnowledgeManager, ServerInterface, and SoapSender classes. These and other helper classes reside in the serverinterface package.
• Ensuring a subcomponent has focus - It is sometimes desirable to set the focus to a subcomponent within an internal frame. For example, when a Concept Editor is opened, the Concept Name text field should get the focus. However, calling requestFocus() generally doesn't work when it called by the same object that created the window. One trick that seems to work is to add a focus listener to the internal frame, and add a call to subComponent.requestFocus() in the gainedFocus() of the listener. For an example, see the code in ConceptFrame.initialize().
• Adding new server method - To add a new remote API method, execute the following steps:
  1. Add any appropriate xml objects in stella on the server side. See powerloom-server/xml-objects.ste for examples.
  2. Implement the new function in stella. By convenntion, all server API methods begin with the prefix SERVER- and reside in the POWERLOOM-SERVER module.
  3. Write a function to test the method. By default, test functions should have the same name as the function as they are testing, and be prefixed with "TEST-".
  4. Add the API method to the *SERVER-DISPATCH-TABLE* using code such as the following: (INSERT-AT *SERVER-DISPATCH-TABLE* "SERVER-<newfunctionName>" (THE-CODE :FUNCTION SERVER-<newFunctionName>)), where <newFunctionName> is the name of the API function you implemented. See powerloom-server/server-interface.ste for examples.
  5. Add the equivalent Java XML objects in the package edu.isi.powerloom.gui.xmlobject
  6. Add an entry in the castor mapping file which describes the new Java XML object. See powerloom-gui/resources/conf/castor-mapping.xml.
  7. Add the Java method signature in the file ServerInterface.
  8. Add a Java implementation for the method. The remote version of the implementation should go in RemoteServerImpl, and should contain code to execute the remote call. See this file for examples on writing the correct RPC code.
  9. The in-process version of the GUI has not yet been implemented. Hence, you will need to write a dummy implementation for the method in LocalServerImpl which does nothing.
  10. Write a method in the KnowledgeManager class which calls the API method you defined in ServerInterface. This method should do any necessary conversion of Java data types to XML Objects (e.g., Strings to PLStrings, booleans to PLStrings, etc), and if necessary, provide caching support.
  11. Your method is now (finally!) ready to be called by the GUI application.

Questions and comments should be directed to Eric Melz or Hans Chalupsky

Last modified: Mon Nov 25 15:13:48 PST 2002