Persistent information must include anything that would be stored in a document’s persistent file.

• Textual Content
• Character formatting (Bold, Italic etc)
• Overall document structure, i.e. Columns and boxes, Header and Footer (types of Boxes)
• Paragraph marks, tabs, tab points etc.

This information can be factored into several elements:

• Atomic data, characters and other things added to a document
• Collection data with no set bounds e.g. paragraphs.
• Collection data with bounds, e.g. columns, boxes and pages (a special type of box)
• Formatting data, on atomic items and collection items, e.g. Bold, italic, heading1, tab marks and borders

(Please add if I’ve missed anything!!)

If we then analyse the above list be can come up with these basic types:

• Atomic document element which is formatable
• A document element which is also a container
• A container document element which is bounded
• A format type

Taking this list we can make these interfaces:

• Formatable (describing something which has formats)
• Format
• DocumentElement
• Container
• Bounded
• Bounds

We don’t need containable because all document elements are containable. The Fomatable interface may also be redundant as I cannot think of a document element that is not formatable!

Object Hirarchy

Using this type of object model allows many types of element to be added at any time in the development lifecycle. The use of the transferable interface allows the description of the type to be unbounded. Therore allowing the existance of many types. The transferable type also allows copy and paste procedures to be carried out on any document element.

There are a couple of interface left off the hirarchy, such as Format and Bounds. I’m not sure at the moment ho to represent a format. It is clear however that an element may have many formats. Therefore it need tohavee a list of some kind.

Another type left off the object model, but is very important is the factories. Inorder to loosly couple the object from each other and be able to easily swap one implementation for another, it is necessary to write factories. These factories create an implementation of the interface but retun the interface itself. This means if we swap TextElement for RichTextElement we only need to change one line in the whole program. Then every creater of that Element will now create a RichTextElement. The interface remains the same but the Implementation differs.

There is one further requiremrnt of the Document Model. It must have a way of notifying the view element when it is changed. This will require some kind of evenet object and listeners. If individual view comonents are notified when the part of the model that they are resonsible for changes, then they can reformat and redraw that part of the view.

To do: Define event model…..

In this system there needs to be some degree of transient information that is view dependant. This information includes the sizes of characters, line breaking and border width etc. These needs to be some way of saving this information between redraws so that the calculating is only done on elements that change or affect other elements.

The size on the screen of any element is dependent on the zoom level, orientation and other factors. It is therefore inappropriate to store this information in the document model. For example the same document element may be represented in several different views simultaneously.

The view data is value-added information that enhances the document data. Its object model could closely follow the document object model, or even re-implement the same interfaces, along with other interfaces specifically for onscreen drawing.

The view information needs to know about pixels and drawing scale in some manner (possibly using a separate scaling object share by all view objects).

There is no need, however, for the view object to know how to format themselves, draw themselves or otherwise affect their drawn representation. It is possible to share formatters and drawers between view elements of the same type. This will mean that the complexity of individual objects can be kept low.

The view objects can act as a bridge between the graphical user interface and the document model. GUI events such as typing can interact with the view elements to alter the document model. This will keep the systems from being to tightly coupled.

Factoring out things to go into the view model I get:

• Value added view objects
  Value added in the way that a paragraph can now have it’s lines broken depending on the width of it’s container.
• Formatters which apply formatting
• Drawers which turn the view object into pixel representations
• Analysis objects such as line breakers

It is difficult to know how much information to generate on the fly, being transient and how much to put into the persistent model. This is shown in the line-breaking problem. A paragraph is a chunk of text with no set line breaks. The line breaks are dependent on how wide its container is and it’s justification. Should the line breaks be stored? Or should they be transient, only calculated when the paragraph is displayed?. I tend to ire on the side of calculating them when the text is formatted for display. This however adds to the complexity of the view model component.

This is just a couple of examples of how this object model may operate.

A person opens a document. The document is read and the document model is constructed. A view component is then created and reads the document model. Individual view model components are creating mapping to document objects. Event listeners are registered to listen to changes in the document model. Overall component event listeners are registered to listen to the view model. The screen is then drawn. Formatters are applied to the view components and store information in the view model component for further use. The views are then drawn by draw objects.

A person places a cursor at a position and then types. The view model component is notified by the key stroaks and then uses a factory to create new document elements. These document elements are then added to their parent document element. The parent document element notifies its views that a change in the model has occurred. The view model requests to be reformatted (line breaking etc. A formatter does the formatting, stores the new changes in the view model. The view is then redrawn.

The model above may seem complicated, it however only represents many small classes that do their own work. This should keep them discrete and allow more types of element to be added to the WP as time passes.

The view is separated from the model. This allows the model to change without affecting the view. It would be possible for the model to reside on a remote machine, or to be shared by several views.