AGUI features

AGraph features. 1

ADMGUI features. 1

ADMEdit features. 2

AAF features. 3

ALab features. 4

AGUI features

AGUI is the basic library of ALES project (many other parts of ALES depends on it). AGUI defines GUI utilities and simplified extensions of Swing framework which make GUI programming easier:

• Improved (extended or wrapped) Swing components – mipt.gui.*TextField, mipt.gui.OptionPane, mipt.gui.FileChooser, mipt.gui.appl.SplashWindow; [mipt.gui.controls] (creating, storing and listening of menus and tools).
• Improved parts of components for choosing single or multiple objects (lists, trees, tables, etc.) [mipt.gui.choice] – the extended components themselves, their models, editors and renderers (which can render implementations of mipt.common.Named and mipt.gui.Viewable interfaces).
  Notes: 1) in Table (unlike List and Tree), the renderer of Named objects is not installed by default; 2) Table, Tree and their models support editing Named objects, but ConvertingCellEditor (that can edit Named objects) is not installed by default.
• Localized and extended Swing UIs of extended components – [mipt.gui.plaf].
• Typical containers (made of standard Swing components) – mipt.gui.*ButtonPane, mipt.gui.LabeledPanel, mipt.gui.choice.SingleChooserDialog.
• Useful objects to ease typical UI operations like showing messages or arranging windows [mipt.gui]: Display, Cascade, ImageSaver, PopupListener; UIUtils, UIConst, Bundle*.
• Abstractions (and their implementations) for managing UI objects without dependency to specific classes – mipt.gui.*IconFactory, mipt.gui.appl.*RootUI.

AGraph features

AGraph library [mipt.gui.graph.*] provides a set of tools to draw plots (XY plots, 3D plots and potentially any charts, histograms, dials and even block diagrams). AGraph is not yet refactored enough (and is not yet supplied with powerful algorithms) to became a comprehensive plotting framework and to compete with JFreeChart, etc. But it already has some advantages and unique features e.g. the easiness of dividing plot area into “zones” (with colors, lines and text labels). Some capabilities of AGraph are demonstrated in applications of NumLabs project. The further development of AGraph will convert it to the framework unifying APIs of multiple free plotting libraries (including internal – already implemented – library). Please do not use this version of AGraph if you can use another free plotting library.

ADMGUI features

ADMGUI consists of two main parts:

• [mipt.gui.data], [mipt.gui.data.impl] – the extensions of Data objects (from [mipt.data] and [mipt.data.impl] from ADAM project) by adding them attributes for GUI applications: name (see mipt.common.Named interface) and icon / font style (see mipt.gui.Viewable interface). It allows proper rendering/editing of Data objects by UI components defined in [mipt.gui.choice], etc.
• [mipt.gui.data.choice] and its subpackages – the framework for convenient and unified processing any choice components containing mipt.data.Data objects; includes implementations for list, compbobox, tree and table through [mipt.gui.choice] components. The model and controller parts of the framework are in [mipt.data.choice], non-UI event listeners/sources – in [mipt.data.choice.event]. The only things usually required from a client code are to fill DataChoiceModel with a set of Data objects, to add listeners (and maybe to call DataChoiceView.initDataMenu() to create default context menu with open/new/delete/rename functionality). If added, listeners will receive notification on selection event, opening event (usually double-click), etc. Table implementation also supports rendering/editing all fields of Data objects including reference fields (of types Data or DataList). DataChoiceManager is a top-level interface of the framework to make reference on it in an application; and the only thing that a client code should change for replacing one choice component to another one (e.g. replacing a list by a table) is a name of DataChoiceManager implementation class (e.g. ListManager -> TableManager). Thus [mipt.gui.data.choice] allows the developer of a final application to forget about Swing (or other UI library) and about differences in APIs of different choice components.

ADMEdit features

Like ADMGUI, ADMEdit contains the framework (i.e. interfaces and their typical implementations) for similar application parts based on Data objects (from ADAM project). ADMGUI deals with components for Data choice (which also can add/remove Data and can perform primitive editing), and ADMEdit deals with editors/forms – complicated components for Data editing. There are two sets of interfaces/classes in ADMEdit – “external” and “internal”:

• “External” part of ADMEdit framework [mipt.aaf.edit, mipt.aaf.edit.data, mipt.aaf.edit.swing] defines some kind of Model-View-Controller pattern for interaction of editors with a main application as well as for separating responsibilities between universal part of an editor and specific (domain-dependent) part – DataEditDelegate. The main “external” interfaces are Editor/DataEditor (notifying a listener and a data changer at the end of editing) and EditAgent/DataEditAgent (an object who knows about the way of presenting Editor’s contents to a user – in a container or in a modal dialog or etc.). It is possible to edit not only single Data objects [mipt.aaf.edit.data] but complicated links between multiple Data objects (one-to-many or many-to-many relationships) [mipt.aaf.edit.data.link].
• “Internal” part of ADMEdit framework [mipt.aaf.edit.form.*, mipt.aaf.edit.swing.form, mipt.aaf.edit.swing.data] eases creation of GUI forms (sets of editable fields). Form metadata (required to define field types, names, etc.) can be obtained automatically from the structure of Data object or any client object; and editing fields can be converted back to client objects of required class [mipt.aaf.edit.form.data]. A form can edit not only single object but multiple objects [mipt.aaf.edit.form.mo], there is Swing table implementation for that feature.

Of course some implementation classes from “external” part of the framework (e.g. DataEditController) depends on “internal” part (e.g. FieldModel). Note that not all packages in ADMEdit depend on Swing and not all of them depend on Data object from ADAM. So if your application forms are built on ADMEdit you can e.g. port them from Swing (e.g. to SWT) without any changes in application logic.

AAF features

AAF (Abstract Application Framework) contains interfaces/classes of Model-View-Controller and Command patterns (as well as some revision of Builder pattern) on the level of a whole application.

• [mipt.mvc] – general models, views, controllers (with classic relationships between them) and general events to notify model or view listeners.
• [mipt.aaf] – extension of [mipt.mvc] concepts for single-document (SDI) applications; introduction of the concepts of Application and ApplicationBuilder (the process of building MVC applications defined here are simpler for a client code than in classic Builder pattern) as well as the optional concept of Parts (according to Composite pattern, with UI-dependent and non-UI-dependent implementations).
• [mipt.aaf.mdi] – extension of [mipt.mvc] model, view, controller and application interfaces for multiple document (MDI) applications; introduction of the new concepts: 
  Doc (that is a Part and MVC pattern implementation with own model, view, controller),        
  Document (application-dependent part of a Doc),      
  DocBuilder (Doc creator like ApplicationBuilder that creates Documents by reflection),
  MDIView (interface for managing visual representation of Docs).
• [mipt.aaf.command], [mipt.aaf.mdi.command] – UI-independent and model-independent implementations of controller behavior at the level of Application, MDIApplication and Doc – according to Command pattern; includes *CommandFactory (Factory pattern interface for commands and its implementation through reflection), *CommandBuilder (builder of a set of commands adding them to CommandStore), builders of applications and docs with command controller, etc.
• [mipt.aaf.mdi.data], [mipt.aaf.swing.mdi.data] – respectively, UI-independent and Swing-dependent implementations of models assuming that attributes of a Doc are stored in Data object (from ADAM project); the term “stored” here can be interpreted literally or not; in the latter case Data stores only view info (e.g. to show title) and an identifier of Doc, but the contents of Document is loaded with the identifier. There are also controller and view for the Data-dependent choice component enabling user selection of a document to open in MDI (selection from a list or from a tree).
• [mipt.aaf.swing], [mipt.aaf.swing.mdi] – Swing-based view implementations for SDI and MDI applications, respectively. javax.swing.Action calls are redirected to Commands. The initialization process includes ControlBuilder that creates menus, menu items, tools, and uses (a tree of) ApplicationResources to get strings and icons for those controls.
• [mipt.aaf.command.resources], [mipt.aaf.swing.resources], [mipt.aaf.swing.resources.mdi] – resource bundles, icons and specific command implementations for typical menus and toolbars. They include work with files (new, open, save, save as, etc.), LookAndFeel changing and help showing (using ACommon library from ADAM project) and so on. Note that support for printing, clipboard operations (with Datas) and undo/redo operations is not yet included to AAF (however it is implemented in specific projects).
• Two applications – mipt.aaf.swing.SwingApplicationBuilder and mipt.aaf.swing.mdi.MDISwingApplicationBuilder – are provided to demonstrate capabilities of AAF framework (with stub models and without any contents of documents); the first application has an applet analogue – mipt.aaf.swing.SwingApplet. Thus AAF is not only very flexible framework (any part of an application based of AAF can be easily changed) but is sufficient for super-rapid creation of final applications.

ALab features

ALab is a framework for super-rapid application development. It extends AAF concepts applying them to “labs” (applications with single-object Data model stored in a file). A lab application/applet consists of modules – for example, complicated forms (built with ADMEdit framework) and/or graphs (typically 2D plots build with AGraph library). A convenient version of Model-View-Controller pattern is implemented on the level of Module (a special module has special view but uses universal Data model); several approaches of inter-module notification are implemented. The menus/tools/commands of labs (implemented according to AAF) are typical for computational applications, they include start/pause/stop functionality, matrix rendering/editing and editing Number properties (see ANum project). Many things can be changed/reconfigured by editing XML metadata file or even command line argument (e.g. modules view in tabbed pane or in internal windows), and many others require trivial change in code like replacing the name of a single class (e.g. data storage format). The framework has a startup system that can launch the same labs/modules as standalone applications, as applets and as documents of MDI interface. Some features of ALab framework can be seen by launching DataReflectionMain or StubApplet or DataMDIReflectionMain; many others (e.g. the simplicity of creating forms and plots) are demonstrated in labs of NumLabs project. The details on launching labs, on managing their files and help resources are in readme*.txt files (included to the distribution archive).