 |
CS 635: Advanced Object-Oriented Design & Programming |
|
|---|
Spring Semester, 1998
Lexi: A Case Study
To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 21-Apr-98
Contents of Doc 20, Lexi: A Case Study
| Reference | slide # 1 |
| |
| Designing a Document Editor | slide # 2 |
| ...Document Structure | slide # 5 |
Reference
Design Patterns: Elements of Reusable Object-Oriented Software, Gamma,
Helm, Johnson, Vlissides, Addison Wesley, 1995, Chapter 2
Designing a Document Editor
Lexi
- what-you-see-is-what-you-get (WYSIWG) document
editor
- Handles text, fonts, graphics, columns of text, etc.
Design Problems
Document Structure
- Internal representation of the document affects
every part of Lexi's design
- All editing, formatting, displaying and textual
analysis require traversing the representation
Formatting
- How to arrange the text and graphics into lines and
columns?
Spelling checking and hyphenation
- How to support theses analytical operations?
- Want to minimize the number of classes we have to
modify to add a new analytical operation or change
an existing one
Design Problems
Embellishing the user interface
- The user's interface includes scroll bars, borders,
and drop shadows
- The user interface embellishments are likely to
change over time
- Need to be able to add/remove/modify
embellishments easily without affecting the rest of
the application
Supporting multiple look-and-feel standards
- Lexi should easily adapt to different look-and-feel
standards such as Motif, Presentation Manager
(PM), Win98, NT, etc.
Supporting multiple window systems
- Use the look-and-feel of the host machine
- Need to support multiple machines
- Design needs to be independent of the windowing
system as possible
Design Problems
User Operations
- Users control Lexi through various interface parts
- These parts are scattered throughout different
objects in the application
- Provide a uniform mechanism both for accessing
this scattered functionality and for undoing
Document Structure
A document is an arrangement of basic graphical
elements such as characters, lines, polygons, circles, and
other shapes
A user views the document as having physical structure
and a logical structure
Physical structure
- lines, columns, figures, tables
Logical structure
- sentences, paragraphs, sections, chapters
The user interface should allow the user to manipulate
these structures directly
That is the user should treat a table as a table not a
bunch of characters
The internal representation should support:
- Maintaining the document's physical (logical)
structure
- Generating and resenting the document visually
- Mapping positions on the display to elements in the
internal representation
Constraints
- Treat text and graphics uniformly
- The implementation shouldn't have to distinguish
between single elements and groups of elements in
the internal representation
- We also need to analyze text for spelling errors,
hyphenation points, etc.
- The analyzes depends on the object being analyzed:
lines do not need to be spell checked
visitors since 02-Apr-98