Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A Method of Allowing Graphical Editor Extensions to be Written Without Editor-specific Code

IP.com Disclosure Number: IPCOM000171742D
Original Publication Date: 2008-Jun-18
Included in the Prior Art Database: 2008-Jun-18
Document File: 1 page(s) / 22K

Publishing Venue

IBM

Abstract

It is often very useful to diagram the design or implementation of a software application in terms of nodes and edges with various properties that represent its control flow (and/or other relationships between its artifacts or states). For example, a diagram of a J2EE-based web application might consist of nodes representing its JSPs and top-level server side business logic and edges representing the top-level application control flow. This disclosure describes a solution to the problem of how to provide an extensible diagram editor such that extenders do not need to have a significant amount of knowledge of the diagram editor itself.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 83% of the total text.

Page 1 of 1

A Method of Allowing Graphical Editor Extensions to be Written Without Editor -specific Code

When implementing such an editor the support for the various types of nodes and edges is typically implemented directly in the code of the editor itself. For example, if you wanted to add support for a new type of node you'd have to modify the editor's code to do so. This approach to diagram editor extensibility has at least two problems. First, requiring the modification of the source code of the editor itself is obviously problematic if multiple third parties want to extend the editor in various ways. Second, it requires intimate knowledge of the implementation of the editor itself, including how it represents nodes and edges internally, how it manipulates them, how it makes it possible for the user to manipulate them, etc.

A somewhat better approach is to separate the code of the editor proper from the implementations of the nodes and edges themselves. The editor framework defines a pair of interfaces (or abstract superclasses) for specifying the general behavior of a node and an edge. This way the editor itself only has to know about these two interfaces, instances of which represent the model objects it manipulates/edits. Concrete implementations of various nodes and edges are contributed separately (in the present case via well-defined Eclipse extension points). This solves the first problem of the previous approach in that t...