com.borland.primetime
or com.borland.jbuilder
and most subsystems have classes in both parallel packages split between
the two. Why the unusual organization? Because JBuilder was designed as
a very flexible IDE, with everything necessary to provide general IDE-style
support in the primetime
packages, and behavior specific to editing
Java code in the jbuilder
packages.
Once you get used to the split personality, the organization is actually
quite logical and well structured. The primetime
packages define
very general-purpose behavior, and never depend on anything in the jbuilder
packages.
Legend
|
JBuilder's Core subsystem manage OpenTools, collections of files, and projects that underlie the user interface. |
|
The general Browser user interface provides a framework for interacting with projects and files. |
|
The specific source code Editor and visual Designer subsystems provide a rich set of end user tools for manipulating Java code. Each of these subsystems is extensible in its own way. |
|
The default JBuilder configuration knows how to compile and run basic Java projects, but the subsystems that manage the Build and Runtime processes are extensible to allow the default behavior to be further tailored. |
|
While the source Editor allows direct manipulation of Java files, automated code generation is also available in JBuilder. The Wizard Framework provides a common look and feel for wizards, and JOT provides the infrastructure necessary to read, alter, and regenerate source code. |
|
JBuilder users become accustomed to a standard look and feel for the environment that is supported by a variety of additional libraries. |
|
Command
interface can be
registered with PrimeTime
to provide this command-line behavior.
|
Filesystem
interface. The contents of entries in Zip files, physical
files, and New "untitled" documents are provided as three Filesystem
implementations in the core VFS implementation.
Much as File instances are used in Java to represent filenames, logical
files in the VFS are identified using instances of a special Url
class (note that this is different from the java.net.URL class.) All virtual
file manipulation is done through static methods on the VFS
class
and passing one or more Url
instances as parameters.
The VFS also supports an in-memory representation of a file as an instance
of the Buffer
class. Buffers can be hold changes before being discarded
or written to disk, and while a buffer exists all VFS operations treat
the contents of the buffer as the "current" state of the virtual file.
|
Project
class, and most projects in a JBuilder environment will actually be instances
of the JBProject
subclass. The project manages a hierarchy of individual
Node
objects, typically either FileNode
objects that represent
a file in the Virtual File System, or LightweightNode
objects that
represent logical concepts such as folders and packages.
The Node System provides a way to associate any number of property values
with each Node
in a project. Lastly, ProjectStorage
implementations
to be registered to read (and optionally write) foreign project file formats.
Keep in mind that JBuilder supports displaying more than one browser at a time. All of the components described below are present in each browser window, each of which maintains its own state. Methods that register new behavior affect all browser windows simultaneously.
|
JBuilder makes extensive use of several convenient Action subclasses that offer more features and flexibility than the basic Swing Action:
UpdateAction
instances dynamically change their state. JBuilder
uses this to change the name of menu items dynamically, and to enable or
disable actions as appropriate.
BrowserAction
instances always receive a reference to a valid Browser
instance. Most JBuilder actions need a reference to the browser that was
active in order to get access to other OpenTools services.
StateAction
instances maintain a boolean state for toggled behavior.
The menu automatically displays checkmarks next to each action whose state
is true, while the toolbar gives these actions a "pressed" appearance.
DelegateAction
instances dynamically connects menus and toolbar
buttons to new actions when the focus changes. These actions are used to
implement the cut and paste actions but can just as easily be applied to
other situations.
|
The user has control over removal of tabs and may hide the entire message
view at any time.
|
A ProjectView
instance can be queried for the currently active
project and the currently selected nodes. The list of open projects is
also available, but is shared among all project views. Lastly, the context
menu available on the project view can be directly influenced by registering
ContextActionProvider
objects with the ProjectView
class.
|
The status bar will display long descriptions for toolbar buttons and menu items are
Longer messages, messages that the user must be guaranteed to see and respond to, and messages that the user needs to interact with should use the Message View facility instead of the Status View.
|
Browser
method.
Each viewer tab is registered as a NodeViewerFactory
. The factory
evaluates whether or not its viewer type is available for a given node.
For available viewers, the factory constructs a NodeViewer
implementation.
The viewer instance provides the tab name and creates a pair of JComponent
instances: one for the structure pane, and one for the content area.
|
TextFileNode
. Each individual node can provide its own syntax
highlighting with a Scanner
implementation, a unique structure pane,
and a CodeInsight implementation.
The editor can also be customized at a global level by registering new
user-selectable keymappings, each of which can borrow freely from our existing
collection of actions implemented in EditorActions
.
|
JavaFileNode
.
It provides a full JavaBean assembly environment that can be extended in
a number of ways. The most obvious is that property editors and customizers
included with JavaBeans are automatically exposed through the designer.
Less obvious ways of extending the Visual Designer include:
|
Note: While there is currently an OpenTools API in place for
the build system, we expect to replace this design in a future version
of JBuilder. The available documentation is extremely limited in part due
to our intention to introduce an incompatible system.
|
RuntimeManager
as implementations of the Runner
interface. Each Runner
provides a name, a configuration panel, and behavior for running and debugging.
Most custom runners will want to share the standard Java runtime and
debugging framework. The class JavaRunner
provides a Runner
implementation that can be subclassed and customized. An application and
applet runtime are installed by JBuilder, and an additional
JSP runtime is added by the Enterprise edition. These all use a standard
runtime and debugging framework.
|
The Java debugger cannot be directly customized, but any custom runtime that uses the standard debugging framework can take full advantage of the debugger.
|
BasicWizard
to provide one or more BasicWizardPage
subclasses,
and registering the resulting wizard instance with the WizardManager
.
|
JOT can be used in a read-only fashion, in which case it can operate on either source code or class files. It can also be used to generate new source files, a facility used by many of the standard JBuilder wizards. The true power of JOT lies in making precise modifications to existing code, preserving existing formatting and comments exactly while making exacting changes to any aspect of the source code. This facility is used by JBuilder's visual designer, by BeansExpress, and by some of the more powerful wizards. JOT's full functionality is also available to OpenTools.
Note: The JavaDoc for JOT was inadvertently omitted from JBuilder 3 Foundation and JBuilder 3.5. An early draft of the JOT JavaDoc is linked here but not yet integrated into the full OpenTools JavaDoc set.
|
Property
subclass, where different subclasses manage different kinds of storage
and provide default values for the property.
Users typically interact with properties through pages on property dialogs.
Registering a PropertyGroup
with the PropertyManager
gives
your OpenTool a chance to provide a PropertyPageFactory
whenever
a property dialog is displayed for a given topic. Topics can include global
properties, properties associated with subsystems such as the editor, and
individual projects and files.
|
The JBuilder help system uses an HTML browser and an indexing scheme based on JDataStore technology.
Note: OpenTools will allowed to integrate with the JBuilder help
system in a future release, including the ability to update help indexes.
|
There are a variety of utility classes included in JBuilder that can
help OpenTools maintain a consistent look and feel. The simplest is to
ensure that all tree controls in your OpenTool descend from SearchTree
to enable the "type-to-search" mechanism.