Skip to content
Robert Silverton edited this page Jul 7, 2014 · 1 revision

Core Framework

A large number of loosely coupled classes and interfaces suited for supporting the building of mid to large scale applications. Specifically, all the code within the coreApp, coreAppEx and coreEditor namespaces.

CoreApp

CoreApp contains all of the general purpose application framework classes that aren't specific to making editors (and hence don’t belong in CoreEditor), e.g. FileSystemProviders, Serialization, Resources, ArrayCollection, ResourceManager.

CoreEditor

This is an application that makes extensive use of the Core Framework and provides the following features.

  • An extensible bare-bones application framework.
  • Context centric UI with Editors and Panels (much like Eclipse, or Visual Studio).

As an application, CoreEditor doesn't do anything useful by itself. It's use is entirely determined by the Extensions it loads.

CoreEditor Static API

A static interface providing global access to various managers and providers. Nearly all code you write for a CoreEditor Extension will use this API in some way. Whether you are writing files to the file system, opening and closing panels and editors, or making use of the CoreEditor Framework's ability to invoke a Command, this API is where to start.

Extension

An Actionscript Application whose sole purpose is to add functionality to CoreEditor during its construction. By convention these applications have the word Extension at the end of their name. i.e. MyCoreEditorExtension.as. If desired, a single Actionscript Project can have multiple Extensions, each building to their own SWF. As Extensions get larger it can sometimes be clearer to group Contributions into related Extensions.

The resulting SWF(s) should be placed at the following path:

<CoreEditor>/extensions/

Then the following file needs updating to include paths to these SWFs.

<CoreEditor>/config.xml

Contribution

A single Resource or other code object added within an Extension’s constructor. For example adding a CommandHandlerFactory is a single Contribution.

Resource

An object added via the CoreEditor.resourceManager.addResource() method. Most of these will be Factories, however there is no type restriction on what you add to the ResourceManager.

Factory

A class implementing the core.app.resources.IFactoryResource interface. Has the ability to create an instance of a particular type of object. The Core framework uses Factories to implement dependency injection via the Factory Pattern, allowing objects to be created dynamically without explicit knowledge of their function.

Nearly all Resources contributed to the CoreApp application via CoreApp.resourceManager.addResource() will be Factories.

Command

A Command is a unique string. A Command’s uniqueness is not enforced by any mechanism, so by convention they use namespace syntax to ensure clashes do not occur. Also by convention, Commands are declared as static constants on a class in the <extension_namespace>.entities package.

A Command serves as a fundamental part of implementing the Command Pattern, whose purpose is to decouple code invoking a command from the code carrying out the work (a CommandHandler).

CommandHandler

A class implementing the core.appEx.core.commandHandlers.ICommandHandler interface. These classes implement a single method, execute(). They are contributed to the CoreEditor API indirectly via their associated Factory: CommandHandlerFactory. One or more CommandHandlers can be associated with a Command. When a Command is invoked, the CommandManager is responsible for resolving which CommandHandler is executed.

Action

A class that describes a button on an View's ActionBar, a menu item on an View's MenuBar or both. Its associated Factory: ActionFactory, is contributed to the CoreEditor API within Extensions. View's use these ActionFactories to create instances of Actions. These actions then monitor the status of the Command they are associated with and will enable/disable themselves based upon the availability of the Command. The View then uses this information to enable/disable the associate button or menu item.

View

A DisplayObjectContainer. All View’s have an IVisualContext controlling them. Represents the visual part of each Panel which is docked on the right hand side of the app. CoreEditor wraps a View in its own Components which provide functionality for showing Actions on its toolbar and/or menubar.

Editor

Much like a View, but has an IEditorContext controlling it instead. Rather than being placed in the scrolling pane on the right, Editors live inside a tab navigator in the centre of the app.

Context

A class extending the core.appEx.core.contexts.IContext interface. A Context wraps up modal logic, and in the case of IVisualContexts, Controller logic too. A Context serves as an object that other code can perform actions upon. A Context usually implements a number of simple interfaces that describe a single aspect of what it is capable of. For example, implementing the ISelectionContext interface allows other code to perform operations on the Context’s current selection, without explicitly knowing the concrete type of the Context.

ActionBar

The area near the top of a View containing buttons for each Action associated with that View.

MenuBar

The area at the top of a View containing a Menu style GUI for showing Actions. e.g. File, Edit, View, etc.

KeyBinding

These can be registered with the KeyBindingManager on the CoreEditor API. A KeyBinding maps a keyboard short cut to a Command.

Validator

A class implementing the core.app.core.validators.IValidator interface. Validators have a boolean state that changes to true when certain conditions are met. For example you could write a validator that switches to true when the mouse is over half way across the screen. Or more usefully, use a Validator whose state is set to true when you have selected a certain type of item in your editor.

Within CoreEditor, a Validator is often associated with a CommandHandler. Allowing the application to determine if a particular bit of behaviour is eligible to be executed.

DOM

Stands for Data-Object-Model. Basically the data of your editor. So a TextEditor's DOM is a sequence of characters, whereas an ImageEditor would be manipulating a DOM of pixels.

URI

A string wrapped up in an Adobe class that provides useful manipulations when the string represents a path. Only objects of this type can be used to specify a file or folder location when working with the Core file system.

Item Editor

A term used often within the Flex framework. An item editor is a Component capable of being used to edit fields in-place within a DataGrid, List or Tree. The PropertyInspector control also supports item editors.