Package com.partnersoft.codex.editors

Undoable editing packages for cogs and text.

See:
Description

Interface Summary

CogField
CogModelListener	Receives notification of changes to a CogModel.
CogPreview
ImageModelListener	A piece of glue that connects microedits from the ImageModel to user interface components, specifically a Swing text control.
TextModelListener	A piece of glue that connects microedits from the TextModel user interface components, specifically a Swing text control.

Class Summary

AbstractCogField	Convenience abstract implementation of a CogField.
AbstractCogPreview
CogBooleanField	Connects a boolean value in a CogModel to a checkbox.
CogColorField	Connects a CogModel to a Swing JTextField.
CogComboBox
CogFieldDocument
CogFormBuilder
CogIconField	Copyright 2006 Partner Software, Inc.
CogModel	Edits a CodexResource containing Cog XML as a Cog.
CogTextField	Connects a CogModel to a Swing JTextField.
ImageModel	Edits a CodexResource as a Image.
ResourceTextArea	Connects a TextModel to a Swing JTextArea.
SubsectionListModel
TextModel
TextTextField	Stupid name.

Package com.partnersoft.codex.editors Description

Undoable editing packages for cogs and text. The editing model for the Partner System is one where every keystroke is saved, rather than a text editor style of editing where the user decides when to save a document. To support per-keystroke persistence without inspiring sheer terror in our users, we have to implement a safety net in the form of unlimited undo. The editor framework does two important, tricky things that multilevel undo requires. Firstly, it manages the two resource models, text and cogs. (We have two resource models to support switching between editing cogs and editing the raw text of a resource.) Since multilevel undo is based on micro-edits, like "insert 'k' into the resource's raw text", we need the undoable actions to apply and rollback micro edits directly to the model. However, each micro edit could apply to a different model, so how do we handle the case of editing raw text, then editing a cog? It seems wasteful to regenerate every model for every edit, so the editor framework gives the models lazy evaluation, where a given model is only generated when it's needed. To take the example of editing text and then editing a cog, the text model would be generated once when the user started editing the resource as text, and then the cog model would be geneated once when the user started editing the resource as a cog. Secondly, the editor framework manages undo visibility, the concept that whatever you undo needs to be shown in the user interface. The editor framework can tell the user interface what form to open, what field in the form to highlight, and what text range in the field to select. The editor framework was designed to be extended, although it probably won't be, and extending the framework is a low-level, insiders-only kind of task. There are two standard editor packages, text and cogs, and there probably won't be any more. It seems like overkill to design an extensible class library that won't be extended, but this library is the minimum to support our developer-complicated, user-friendly concept of editing.

Author:

Russell Cagle Copyright 2006 Partner Software, Inc.

See Also:

CodexResourceModel, com.partnersoft.codex.Edit, com.partnersoft.codex.EditManager