|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Interface Summary | |
ApplicationListener | Interface which listeners of application events must implement. |
ApplicationStatus | ApplicationStatus is an interface used in remote access to advertise application status. |
XalDocumentListener | Interface for common document event listeners. |
Class Summary | |
AboutBox | An About Box window that displays information about the application. |
ActionFactory | ActionFactory is a factory class with methods that can instantiate actions for use in menus and the toolbar. |
Application | The Application class handles defines the core of an application. |
ApplicationAdaptor | ApplicationAdaptor is the abstract superclass of the custom applicaton adaptors each of which acts as a delegate for its corresponding application. |
ApplicationStatusService | ApplicationStatusService handles application status queries on behalf of the running application instance. |
Commander | The Commander manages the commands (actions and menu handlers) that are used in toolbars, menu items and menus. |
Console | The Console captures standard output and standard error streams. |
FileChooserFactory | Deprecated. Replaced by FileFilterFactory |
HelpWindow | The help window that displays documentation on the application. |
ImageCaptureManager | ImageCaptureManager manages the file chooser used to save image captures of the main window. |
PrintManager | Manage document printing. |
Util | Utility class providing convenience methods for use in the application framework. |
XalDocument | The base class for custom documents. |
XalWindow | The base class for custom windows that are the main windows for documents. |
Provides a framework for building document based applications. The framework provides a common look and feel for your applications and each application inherits a common set of implemented features. The framework employs a standard cross-platform look and feel that should be familiar to most users. The architecture was designed to be both extensible and customizable. This allows applications written today to inherit new features in the future and it also offers developers quite a bit of freedom to customize their applications. Applications inherit most of the features simply by using the framework as a foundation.
An application console is provided to capture and display standard output (black text) and standard error (red text).
A standard menu is provided that includes "File", "Edit", "View", "Window" and "Help" menu items. The "File" menu includes commands for creating new documents, opening, closing and saving documents, opening recent documents, printing a document and quiting the application. The "Edit" menu has commands for simple text editing (e.g. cut, copy, paste and "select all") and for editing preferences. The "View" menu has a command for opening the application console. The "Window" menu has commands for capturing the window as a PNG file, cascading all of the application's open documents, showing or hiding all open documents and bringing an open document to the front. The "Help" menu has commands for viewing application information (name, authors, description, etc.) and for viewing application help. A standard toolbar is also provided for some common commands. Developers can define their own custom commands and modify and add menus and menu items as required. For multi-document applications, each document may define its own menu bar and menu items. By default each document inherits the menu definitions from the application's menu definitions.
ApplicationAdaptor
and provides application
specific information that the framework needs and it also provides hooks for custom
control at the application level. The document class extends from XalDocument
and provides the framework with document specific information and also provides hooks
for document control. The document window class extends XalWindow
and
defines the main window for a document. Note that the framework supports the
popular "Model-View-Controller" (MVC) paradigm. The window is implemented as
the document window, the document implements the controller and the developer
provides a custom model for the application specific business logic. A reference
to the model typically resides in the document class.
The main application class should implement the main()
method as
the entry into the application. This method should then call Application.launch()
and pass to it as the argument an instance of your main application class. You
must implement readableDocumentTypes()
to return an array of file
extensions of readable files, writableDocumentTypes()
to return an array of file extensions of writable files, newEmptyDocument()
to return a new instance of your document class, newDocument()
that
takes a URL as an argument to return a new instace of a document class that
represents the file specified by the URL and the developer must implement the method
applicationName()
to provide a name for the application. See the
ApplicationAdaptor
class for other methods to optionally override.
Each document class should implement the makeMainWindow()
method to return a new instance
of your main document window class. Also the saveDocumentAs()
method
should be implemented to save a document to the specified URL. Note that
gov.sns.tools.XmlDataAdaptor
is a convenient tool for encoding and decoding
data including documents in XML format and it implements gov.sns.tools.data.DataAdaptor
to provide APIs that are independent of storage backing. XmlDataAdaptor
is
an excellent choice for encoding and decoding documents. However, the application
framework allows the developer the freedom to encode their document as they wish.
The writableDocumentTypes()
method allows each document to specify which
file extensions can be written by the document. By default this method simply returns
the same array of file types as specified by the application's ApplicationAdaptor
subclass. It is only necessary to override this method in the document if your application
supports more than one kind of document. A document in a multi-document application may
also choose to override the getCustomMenuDefinitionPath()
method to call
Application.getAdaptor().getPathToResource()
with the name of the document's
custom menu definition.
The document window class must define the main window used to present the document to the user. The developer is free to layout the window as desired.
Three resources ("About.properties", "Help.html" and
"menudef.properties") are typically provided to support the application. By default the
application will look for these resources to reside in a folder named "resources" that
sits at the same level as the application's subclass of ApplicationAdaptor
.
You may override the location of resources by specifying the locations in
ApplicationAdaptor
. Each document may define its own menu definitions
and these properties files should be added to the resources folder. The "About" resource
contains application information that will be displayed in an About box. The format
is a standard Java properties format. The developer should provide this file and the
properties to define are: "name", "version", "date", "authors", "organization"
and "description". The "authors" entry may contain a comma delimitted list of
authors. The "Help" resource is simply user documentation written in standard HTML
format. This documentation will be displayed in a help window upon user request.
The developer should provide this help file. The "menudef" resource is an
optional properties file that defines the menus and toolbar items that differ
from the inherited menudef resource. The "menudef" format is a standard Java
properties format. The menu bar is defined as a space delimitted list of
menu identifiers. A menu label is specified by defining a key as the menu identifier followed by
"_label" and then providing the label as text. For example you might define a
menu identifier as special
and then define special_label = Special
to label the menu as "Special". The menu is populated similarly except you
append "_menu" to the menu identifier as in special_menu = start pause stop
to have the specified menu items. Using a dash, "-", between menu items will
insert a menu separator. Prepending a menu item with a carat, "^", indicates that
the menu item is itself a menu thus allowing for cascading menus. Prepending an item (menu or
toggle bar item) with a "*" indicates that the item is a group of mutually exclusive
items. You then must define the group with a list of its items and these items will appear
as radio-toggle buttons in the view.
You must associate commands with menu items. A command must be an action which
fires when the menu item is selected and released, a button model which fires
when the menu item is selected or a handler which fires when a
menu is selected (e.g. a handler may be used to populate a menu). One specifies
an action (or button model) by appending "_action" to the menu item identifier as in "start_action" and
then providing as the data a unique command identifier. Similarly you can
define a handler by appending "_handler" to a menu item identifier. Custom logic
to implement actions and handlers may be defined in any of your application's
three foundation classes as appropriate. Your commands may be either application
or document specific. See ApplicationAdaptor
, XalDocument
and XalWindow
for the hooks that allow you to define your custom
action and handler logic.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |