PSICAT Developer Manual
Welcome to the PSICAT Developer's Manual. This document is targeted at users who are interested in learning how PSICAT works internally and at developers who are interested in adding new functionality to PSICAT. This document is divided into four parts:
- Part 1 provides a general introduction to PSICAT and PSICAT-related concepts
- Part 2 provides an overview of the PSICAT architecture and the various core PSICAT objects and services
- Part 3 walks you through using the architecture and services to implement your own plug-ins
- Part 4 provides a comprehensive reference of all of the existing PSICAT plug-ins, including the data types, services, and extension points they provide
After reading this document, you should understand how PSICAT works and be able to implement your own plug-ins to PSICAT.
Part 1: Introduction to PSICAT Concepts
This section provides an overview of the core PSICAT concepts from the developer's perspective. If you haven't already, you should check out the Overview page to familiarize yourself with the philosophy and goals of PSICAT. Also, PSICAT is built upon the Eclipse Rich Client Platform (RCP) and utilizes the Eclipse Graphical Editing Framework (GEF), so familiarity with these technologies will be quite helpful. After reading this section, you should understand the core PSICAT concepts and how they relate to each other.
Models
Because PSICAT is focused on capturing data, it introduces the concept of a 'model'. Models define what data is captured for a particular object. Models can also define and enforce constraints, such as not allowing any child models or requiring that a specific property be a number. Almost everything the user interacts with in PSICAT is a model.
Models are simple, key-value pair data structure. Each model has three intrinsic attributes--an id, type, and parent id. The id attribute uniquely identifies the model to PSICAT. The type attribute provides an indication of the object that the model represents. The parent id attribute provides the id of the model's parent. This allows for hierarchical trees of models. Beyond these three intrinsic attributes, each model can have an arbitrary number of key-value pair 'properties'. Below is an XML representation of the model data structure:
<model id="2" parentId="1" type="psicat.core.interval.Interval"> <property name="depth.top">0.70</property> <property name="depth.base">1.20</property> <property name="grainsize.base">9.60</property> <property name="grainsize.top">9.60</property> <property name="contact.type">gradational</property> <property name="contact.angle">8.53</property> </model>
In this case, the model is representing an object of type psicat.core.interval.Interval. From the model, we can see that psicat.core.interval.Intervals define a top and base depth, a top and base grain size, a contact type, and a contact angle.
The model data structure is extremely flexible; it provides a mechanism for representing just about any high-level data structure.
See PSICAT Internals: Models
See PSICAT Internals: Model Manager
Diagrams and Columns
In PSICAT there is a distinct separation between the data and the visual representation of that data. As explained in the previous section, the data is managed via models. To manage the display the data, PSICAT introduces the concepts of 'diagrams' and 'columns'. Columns are responsible for taking a model and creating a visual representation of it. Generally, a column is associated with a single or a small number of specific model types. Columns are also responsible for providing the drawing and editing tools used to interact with the models.
Diagrams simply define a list of columns and the order they should be displayed in. If no column included in the diagram knows how to display a particular model, that model will not be displayed. This allows the user to define exactly what type of data gets displayed, and (to a lesser extent) how that data gets displayed. Users can define multiple diagrams that are suited for different tasks, e.g. one diagram that has a limited number of columns for entering a specific type of data and one diagram that includes all of the available columns so that all of the collected data can be displayed.
See PSICAT Internals: Diagrams
See PSICAT Internals: Diagram Manager
Plug-ins
As mentioned in the introduction, PSICAT is built upon the Eclipse Rich Client Platform (RCP). The Eclipse RCP is built around the idea of plug-ins. Plug-ins are small, self-contained software modules that provide new functionality and features to a larger software system. The Eclipse RCP itself is just a collection of plug-ins that provide a common framework for building Java applications. Similarly, all of the functionality in PSICAT is contributed via plug-ins. Every data type and column is contributed via a plug-in. This plug-in based approach makes PSICAT highly extensible because new functionality can easily be added by simply creating and contributing a new plug-in that implements the functionality you need. This approach also makes PSICAT highly customizable because you can replace existing functionality with your own implementation.
See PSICAT Internals: Architecture
See Extending PSICAT: Creating a new model type and column
Part 2: PSICAT Internals
This section provides an overview of the PSICAT architecture and the various core PSICAT objects and services. The information explained here will be vital when it comes to adding new features to PSICAT.
Architecture
The architecture of PSICAT has multiple layers like an onion. The outer layers build on the functionality provided by the layers below it. Currently, the architecture consists of five main layers:
- Eclipse Rich Client Platform (RCP): The RCP layer provides the basic application platform. At the heart of the platform is the concept of plug-ins and extension points. On top of these concepts, it provides a framework for building application consisting of a workbench that can contain multiple views and editors.
- Eclipse Graphical Editing Framework (GEF): The GEF layer builds on the RCP editor concept by developing a Model-View-Controller (MVC) framework for building graphical editors. In the GEF MVC framework, the Model component can be any Java object. For the View component, the GEF introduces the concept of a figure. Figures know how to draw something on the screen. Between the Model and the View is the Controller. The Controller is responsible for mediating between the Model and the View. It passes the properties from the Model that the View needs to know to draw itself properly. It is also responsible for making sure that changes performed by the user in the graphical editor are propogated to the model. This approach de-couples the model from the visual representation of the model. The GEF also provides a 2D drawing library that the figures use to do the actual drawing to the screen.
- CHRONOS Modeling Framework (CMF): The CMF builds on the previous two layers by providing Java interfaces for domain models, columns and diagrams with IModel, IColumn, IDiagram. It also provides various useful services for working with these Java interfaces.
Part 3: Extending PSICAT
This section will walk you through creating multiple? PSICAT plug-ins. It will also talk about other ways to extend PSICAT like adding new lithology and symbol schemes.
Part 4: PSICAT Plugin Reference
This section will provide a comprehensive reference of all of the existing PSICAT plug-ins, including the data types, services, and extension points they provide
