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:
- Add any appropriate xml objects in stella on the server side. See
powerloom-server/xml-objects.ste for examples.
- Implement the new function in stella. By convenntion, all
server API methods begin with the prefix SERVER- and reside
in the POWERLOOM-SERVER module.
- 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-".
- 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.
- Add the equivalent Java XML objects in the package
edu.isi.powerloom.gui.xmlobject
- Add an entry in the castor mapping file which describes the new Java XML object. See
powerloom-gui/resources/conf/castor-mapping.xml.
- Add the Java method signature in the file ServerInterface.
- 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.
- 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.
- 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.
- 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
PowerLoom is a registered trademark of the University of Southern California.
Last modified: Mon Nov 25 15:13:48 PST 2002