This document was last modified March
Composer Module Summary
XP Notes and Warnings
Windows Front End
Mac Front End
UNIX Front End
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:
Composer was not 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
A web site editor.
A high end page layout tool.
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
||Main API declarations - all global functions begin with
||Structures, data types, global defines. Structure names begin with
"EDT_". Defines and data types begin with "ED_"
||Function declarations common to each platform's front end. All begin
||Message strings shared by all platforms. [In Windows: After adding
or changing strings, copy this file to "allxpstr.rc" for use by the resource
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:
||The "Tape File System" used for file IO
||File and memory data streams
||Defines for data types to editor classes
Implementation files used exclusively by Composer:
||Implementation that maps global EDT_ functions to CEditBuffer
methods and other editor objects.
||Edit buffer - contains and manages the HTML data object tree
||HTML data objects
||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!)
||Java-related code for Editor Plugins
||File and image loading, saving, and publishing
||Misc. helpers and classes used by selection, object sizing, autosave
||Tape file system implementation
||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
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)
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.
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
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":
XML Editing (modify HTML tag handling to conform to XML standards.)
And fix outstanding bugs!