This book is a work in progress, comments are welcome to: johno(at)johno(dot)se

JuiceMaker

Introduction

JuiceMaker was an editor intended to ease the creation and editing of .juice files. It offered a standardised heirarchical tree view of the data in a .juice file / namespace, various means of editing, copying and pasting of this data. In addition, a framework was created for writing custom editor plugins to further enhance editing capabilities for application specific data structures.

JuiceMaker was a standard MFC Document/View SDI application, with the main frame split into a left tree view and a right normal view, similar to many of Microsofts products/editors. The standard visualization of a given .juice file / namespace was in the left tree view, which displayed all instances in a namespace. The right view is used for standard and custom editor plugins.

Creating .juice from scratch

As mentioned in the Juice section, the primary intent of JuiceMaker was to support designers in creating .juice files.Typically .fruit files were created using an external text editor, usually by a programmer who knew how the data should be formatted in order to be used by the code. Once this was donea user could create a .juice file from scratch by creating a new document (File/New) and including the appropriate .fruit files (Type/Include). Once this was done, instances of the custom types could be created (Instance/New).

Editing existing .juice

The most common way of using the JuiceMaker revolved around using the tree view (JuiceTree) to manipulate the namespace. In general, right clicking on an instance would bring up an editor dialog for the given type. All types except for CLASSes could be edited (CLASSes could not since they had a fixed structure. However, members of any CLASS which are not themselves CLASSes could of course be edited).

Customisation (C++)

Initially (ca Josephine), this was the primary way that JuiceMaker was used. When Ground Control 2 commenced and it was decided that Juice would be the data definition language for that project as well, more work was done in order to support more advanced and specific editors

The basic idea was to use reflection to inspect the TYPE of a given Juice instance, and based on that information launch a customised editor for instances of that type. Technically, this was achieved by parameterising the application with a custom JuiceEditorFactory (Abstract Factory pattern) that would create the correct editor instances at run-time.

The JuiceEditorFactory mechanism worked in the following manner:

1. When the user selected an instance in the JuiceTree, the application asked its JuiceEditorFactory object to create a JuiceEditor for this TYPE of object, with specific classes being mapped to the TYPEs string.
2. If such a mapping existed, an editor instance was created and returned to the applications, which then handled input forwarding from the right hand view to this editor.
3. This editor existed until the user selected a new instance in the JuiceTree for which there was an TYPE-editor mapping, in which case the old editor was destroyed and the new one replaced it.

Over time, both standard editors and application/project specific editors evolved. One that was of interest was the SpreadSheetEditor, which displayed a MS Excel style spreadsheet for any SCRIPTCLASS instance which supported only a single typ as content (for example a CLASS). The members of the included CLASS type were displayed as columns, and the various instances as rows. This allowed for ease of comparison between the instances in the SCRIPTCLASS/"list", as well as copying/pasting of values.

The evolution of these types of editors, which were implemented quite crudely using simple GDI drawing calls and completely without the support of any MFC widgets, were the first seeds of IMGUI style editing. Also, as the data constructs supported by the SpreadSheetEditor (structs in a list) are basically a relational table, this kind of editing became important as my thoughts on IMGUIs and persistence evolved.