This document was last modified March 30, 11:45am.

Composer Module Summary

Background
Architecture
    Cross platform
    XP Notes and Warnings
    Windows Front End
    Mac Front End
    UNIX Front End
Future Plans

Background

The first Netscape HTML editor was first introduced in "Navigator Gold 2.0" in 1996, where the "Gold" aspect was essentially the Editor. With version 3.0, Mac and UNIX versions were available. With Communicator 4.0, the editor was renamed "Composer" and was used to write mail messages as well (the "Message Composer").
Composer was designed to be:

Easy to use
Easy to implement
Mostly WYSIWYG (What-you-see-is-what-you-get)
Able to edit any HTML document (Legal or not)
Produce legal HTML
Produce HTML e-mail

Composer was not designed to be:

A web site editor.
A high end page layout tool.

Architecture

Most generally, there are two layers to the implementation: the Cross Platform ("Backend" or "XP" ) system and the Front End ("FE") code specific to each platform. We will use the term "Editor" to refer to the components common to the Page Composer module and Mail Message Composer modules -- the XP Editor core and the View class shared by the Page and Message components. The Editor XP system consists entirely of C++ objects internally, but the interface to each front end is through the global "EDT_" C functions. Likewise, callbacks to each Front End are global "FE_" functions, even though the Front Ends are written mostly in C++.

Cross platform ("Backend" or "XP" code)

The Editor API (as well as shared string definitions) header files are in include:

edt.h	Main API declarations - all global functions begin with "EDT_"
edttypes.h	Structures, data types, global defines. Structure names begin with "EDT_". Defines and data types begin with "ED_"
fe_proto.h	Function declarations common to each platform's front end. All begin with "FE_"
allxpstr.h	Message strings shared by all platforms. [In Windows: After adding or changing strings, copy this file to "allxpstr.rc" for use by the resource compiler.]

EDT.H and EDTTYPES.H are exclusively used by Composer, others files include declarations for other modules as well. There are also some Composer-specific defines and structure members contained in STRUCTS.H; most notably, those in the important MWContext global structure The cross platform code is mostly contained in these files in lib/layout:

editor.h
fsfile.h	The "Tape File System" used for file IO
streams.h	File and memory data streams
edttypep.h	Defines for data types to editor classes

Implementation files used exclusively by Composer:

editor.cpp	Implementation that maps global EDT_ functions to CEditBuffer methods and other editor objects.
edtbuf.cpp	Edit buffer - contains and manages the HTML data object tree
edtele.cpp	HTML data objects
edtcmd.cpp	Interface for "commands" that can be undone (from an early attempt at multiple-level undo system - this layer should be eliminated if we stick with single-level undo!)
edtjava.cpp	Java-related code for Editor Plugins
edtsave.cpp	File and image loading, saving, and publishing
edtutil.cpp	Misc. helpers and classes used by selection, object sizing, autosave timer, etc.
fsfile.cpp	Tape file system implementation
streams.cpp	File and memory streams implementation

Other files in lib/layout include Composer-specific code dealing with layout in a Composer view window. One way to find most of the Composer-specific areas is to search for "#ifdef EDITOR" in the source files.

XP Notes and Warnings

The main "trick" to producing an editable document is the hook into the output of the HTML parser, which constructs a hierarchical tree of CEditElement (and derived classes) objects from the HTML tokens. We then "relayout" by iterating over the tree of edit elements to produce HTML tokens which are fed to the layout engine, which constructs its data structures as lists of layout element structures. The layout engine, of course, directs the front ends to render the data on screen.
When a user modifies the document by typing or inserting or deleting elements, the Editor elements are modified first, then fed through the same relayout mechanism.
There is a very tight and complicated entanglement between the layout code and the editor -- the former understands where the user current selection is (what element the user clicks on)
(This discussion to be expanded soon!)

Rules for keeping edit elements and layout elements in synch
Explain file IO and the "Tape file system"

Windows Front End

The Windows Front End is an MFC-based architecture mostly adhering to the Document/Frame/View model, except that CDocument is not as important as it normally is in MFC programs. The CFrame- derived classes contain the User Interface elements such as toolbars, status line, and menus (the "chrome") -- here is the class hierarchy:
CFrameWnd -> CNSGenFrame -> CGenericFrame -> CMainFrame -> CEditFrame
The Browser window is a CMainFrame object. Likewise, there is a hierarchy of View classes:
CView -> CGenericView -> CNetscapeView -> CNetscapeEditView
Most of the Windows messages are routed to the CNetscapEditView.

Winfe Notes and Warnings

Window creation, loading of contents, and file saving is managed in CEditFrame and CGenericFrame (all Editor-specific CGenericFrame methods are implemented in edframe.cpp.) To edit a URL given just the URLstring, simply call the Windows-global function FE_LoadURL(MWContext *pContext, BOOL bEdit) with bEdit = TRUE. This function will also load the URL into a Browser window if bEdit = FALSE. This function will bring up an existing window if the URL is already being edited, and compartmentalizes all the requirements such as hooks for Composer Plugins (which require Java).
The Editor shares the Browser code for many purposes, such as network interface, printing, etc., thus the MWContext type (a member of the MWContext structure) for an Edit document is "MWContextBrowser", the same as for the Browser module. Thus "MWContextBrowser" does not uniquely identify the Browser -- use EDT_IS_EDITOR(pMWContext) if you don't want an Editor. Ideally, this should be changed from MWContextBrowser to MWContextEditor to match usage on other platforms.
Be careful if you add or change the chrome in a browser frame (CMainFrame) This is a common error that happens among Netscape developers - they forget to check if we are in a browser or editor frame (use IsEditFrame() or EDT_IS_EDITOR(pMWContext) if you have a pointer to a MWContext struct.

Mac Front End

The Macintosh Front End is mostly written in C++ based on PowerPlant classes. The main editor functionality can be found in CEditView.cp (based on class CHTMLView) and CEditorWindow.cp (based on class CBrowserWindow).

UNIX Front End

(To be completed)

Future Plans

This is a short version of the many ideas Netscape designers and engineers have suggested, as well as input from our customers:

Complete work in progress. It is important to realize that this code release is happening in the middle of our previously planned development cycle. Thus there are key areas that are "works in progress":

Table editing. We have selection and enhanced cell, row, column property dialogs mostly done. We need to complete:

Dynamic resizing of table, row, and column height and width
Copy/Paste and Drag&Drop of selected table elements.
Convert/reformat selected paragraphs into a table.

Improve the performance of HTML layout based on Mariner enhancements. This includes much faster table layout and incremental rendering.

Lists:

Fix problems with copy/pasting and indenting/outdenting of list items.
Make it easier to end a list by hitting Enter key twice
Make it easier to start a list by entering a specified character.

Copy data from a Browser or Mail Message in HTML format so it can retain attributes when pasted into Composer. This entails converting the layout elements into something like CEditElements and using the Netscape's HTML clipboard format, or producing a new format consisting of raw HTML text that is reparsed when pasted into Composer.
Change the Editor API to conform to the HTML 4.0 Document Object Model (DOM). This should be done in coordination with adding the DOM API to the current layout engine.
Replace current layout engine with a new systems conforming to HTML 4.0 DOM.
Improve WYSIWYG behavior, such as wrapping text around images, support for Cascading Style Sheets (CSS), floating layers, etc. This will probably require a new layout engine.
Add support for HTML elements currently displayed as "Unknown HTML":

Forms
Frames
Plugins
Java Applets
Layers

XML Editing (modify HTML tag handling to conform to XML standards.)
Multi-level undo.
JavaScript plug-ins. (Possibly using the HTML 4.0 DOM).
And fix outstanding bugs!