copyright © 1995-2004 active frameworks inc. - all rights reserved - v2.0document editor - page...

Copyright © 1995-2004 Active Frameworks Inc. - All Rights Reserved - V2.0 Document Editor - Page L2-1

PS95&96-MEF-L9-1 Dr. M.E. Fayad

Document Structure

• Goals

• Recursive Composition

• Glyphs

• Design Patterns: Composite Pattern



Document Structure: Goals & Constraints

• Maintaining the document’s physical structure

• Generating and presenting the document visually

• Mapping positions in the visual rendition to elements in the internal representation

• Using one set of formatting and manipulation mechanisms to deal with both text and graphics



Document Structure: Recursive Composition

Q q

Q q space

composite (column)

composite (row)

composite (row)

composite row

Recursive Compositionof text and graphics

Object Structure forRecursive Composition

Recursive composition is a common way to represent hierarchically structured information by building increasingly complex elements out of simpler ones.



Document Structure: Glyphs

• A Glyph is an abstract class. Its subclasses are specialized to support different graphical elements, both primitive (characters and images) and structural (rows and columns).

• Glyphs’ responsibilities: They know

1. How to draw themselves

2. The space they occupy

3. Their children and parent

4. A low-level presentation for themselves



Document Structure: Composite Pattern

• Recursive composition can be used to represent potentially complex, hierarchical structure

• Programming languages can’t express this concept directly

• Composite pattern is used to document the recursive composition technique as it manifests itself in object-oriented systems

• Composite captures the essence of recursive composition in object-oriented terms



• Goals & Constraints

• Encapsulating the Formatting Algorithm

• Compositor and Composition

• Design Patterns: Strategy Pattern

Formatting



• Representation and formatting are distinct: The ability to capture the document’s physical structure doesn’t tell us how to arrive at a particular structure.

• The editor must break text into lines, lines into columns, and so on, taking into account the user’s desires.

• Constraints :

– Flexibility

– Changeability

– The user configurations

• Formatting = breaking a collection of glyphs into lines, breaking lines into columns, and breaking columns into pages.

• The terms formatting and linebreaking are used interchangeably.

Formatting: Goals & Constraints



• Formatting algorithms tend to be complex.

• The design of Lexi:

– Easy to change the formatting algorithms at least at the compile-time, if not at the run-time as well.

– Encapsulate the formatting algorithm in an object. This will isolate the algorithm and make it easily replaceable.

• More specifically:

– Define a separate class hierarchy for objects that encapsulate formatting algorithms

– The root of the hierarchy define an interface that supports a wide-range of formatting algorithms, and each subclass will implement an interface to carry out a particular algorithm

– Then, we can introduce a Glyph subclass that will structure its children automatically using a given algorithm object

Formatting: Encapsulating the Formatting Algorithm



Formatting: Compositor & Composition

Compositor

Compose()SetComposition()

Glyph::Insert(g, i)compositor.Compose()

Composition

Insert(Glyph, g, int i)

Glyph

Insert(Glyph, int i)

children

ArrayCompositor

Compose()

TextCompositor

Compose()

SimpleCompositor

Compose()

compositor

composition

Composition and Compositor Class Relationships



• Encapsulating an algorithm in an object is the intent of Strategy Pattern

• Compositors are strategies; they encapsulate different formatting algorithms

• A composition is the context for a compositor strategy

Formatting: Strategy Pattern

Strategy Pattern

The key to applying the pattern to a particular problem is coming up with general strategy and context interfaces that support a broad range of algorithms.



Embellishing the UI


• Transparent Enclosure

• Monoglyph

• Design Patterns: Decorator Pattern



• Two embellishments in Lexi’s user interface:

• The first adds a border around the text to demarcate the page of text

• The seconds adds scroll bars that let the user view different parts of the page

• Shouldn’t use inheritance to add embellishments to the user interface, why?

– To achieve flexibility » to make it easy to add or remove these embellishments

(especially at run-time) and without changing other classes

Embellishing the UI: Goals & Constraints



• Transparent enclosure combines the notion of:1. Single-child (or single-component) composition and

2. Compatible interface

• Clients generally can’t tell whether they are dealing with the component and its enclosure, especially if the enclosure delegates all its operations to the component.

• But the enclosure can also augment the component’s behavior by doing work of its own before and after delegating an operation.

• The enclosure can also effectively add state to the component.

Embellishing the UI: Transparent Enclosure



Embellishing the UI: Monoglyph

MonoGlyph

Glyph

Draw(Window)

component Draw(Window)

Scroller

Draw(Window)

Border

Draw(Window)DrawBorder(Window)

MonoGlyph ClassRelationships



Decorator Pattern

The Decorator pattern captures class and object relationships that support embellishment by transparent enclosure. In the Decorator pattern, the term embellishment refers to anything that adds state or behavior to an object.

Embellishing the UI: Decorator Pattern



Supporting Multiple Look-and-Feel Standards


• Abstracting Object Creation

• Factories and Product Classes

• Design Patterns: Abstract Factory Pattern



- The Lexi’s design goals are:

• To make it conform to multiple existing look-and-feel standards

• To make it easy to add support for new standards as they emerge

- This is a portability issue

Supporting Multiple Look-and-Feel Standards: Goals & Constraints

The Lexi’s Design must support ultimate flexibility:

Changing Lexi’s look and feel at run-time



Assumptions:

• A set of abstract Glyph subclasses for each category of widget glyph

• A set of concrete subclasses for each abstract subclass that implement different look-and-feel standards

• Lexi must distinguish between widget glyphs for different look-and-feel styles

• This can be achieved by abstracting the process of object creation

Supporting Multiple Look-and-Feel: Abstracting Objects Creation



Supporting Multiple Look-and-Feel: Factories & Product Classes

return new MotiScrolBar

GUIFactory

CreateScrollBar()CreateButton().................

MotiFactory


PMFactory


MacFactory


return new MotiButton

return new PMScrolBar

return new PMButton

return new MacScrolBar

return new MacButton

GUIFactory Class Hierarchy



Supporting Multiple Look-and-Feel: Factories & Product Classes (cont’d)

Glyph

Abstract ProductClasses

&Concrete Subclasses

ScrollBar

ScrollTo(int)

Button

Press()

Menu

Pupup()

MotiScrollBar

ScrollTo(int)

MacScrollBar

ScrollTo(int)

PMScrollBar

ScrollTo(int)

MotiButton

Press()

MacButton

Press()

PMButton

Press()



Supporting Multiple Look-and-Feel: Abstract Factory Pattern

Abstract Factory Pattern

Factories and products are the key players in the Abstract Factory pattern. This pattern captures how to create families of related product objects without instantiating classes directly

The Abstract Factory pattern’s emphasis on families of products distinguishes it from other creational patterns, which involve only one kind of product object



Supporting Multiple Window Systems


• Encapsulating Implementation Dependencies

• Window and WindowRep

• Design Patterns: Bridge Pattern



• This is another portability issue.

• Lexi must support multiple windows

• Lexi is designed to run on as many platforms as possibe for exactly the same reasons we support look-and-feel standards

Supporting Multiple Window Systems: Goals & Constraints



Supporting Multiple Window Systems: Encapsulating Dependencies

glyph->Draw(this)Glyph

Draw(Window)

Window

Redraw()Iconify()Lower()........DrawLine()........

ApplicationWindow IconWindow

Iconify()

DialogWindow

Lower()

glyph

owner->Lower()



Supporting Multiple Window Systems: Window & WindowRep

WindowImp

DeviceRaise()DeviceRect(...)........

Window

Raise()DrawRect(...)

ApplicationWindow IconWindow DialogWindow

imp

MacWindowImp


PMWindowImp


XWindowImp




Supporting Multiple Window Systems: Bridge Pattern

Bridge Pattern

The relationship between Window and WindowRep is an example of the Bridge Pattern. The Bridge Pattern allows separate class hierarchies to work together even as they evolve independently. The Bridge Pattern allows for maintaining and enhancing the logical windowing abstractions without touching window system-dependent code, and vice versa.



User Operations


• Encapsulating the Request for a Service

• Commands and Histories

• Design Patterns: Command Pattern



• Lexi provides different interfaces for the following operations:

– Creating a new document

– Opening, saving, and printing an existing document

– Cutting selected text out of the document and pasting it back in

– Changing the font and style of selected text

– Changing the formatting of text

– Quitting the application

– and plus many more...

• Lexi’s is also designed to support undo and redo of most but not all its functionality

• The challenge is to come up with a simple and extensible mechanism that satisfies all of these needs

User Operations: Goals and Constraints



User Operations: Encapsulating the Request of a Service

Command

Execute()

PasteCommand

Execute()

if (document is modified) { save->Execute()}quit the application

QuitCommand

Execute()

SaveCommand

Execute()

buffer

FontCommand

Execute()

newFont

paste bufferinto document

make selectedtext appear innewFont

pop up a dialogbox that lets theuser name thedocument, and then save thedocument underthat name

save

Partial Command Class Hierarchy



User Operations: Commands & Histories

Glyph

Command

Execute()

MenuItem

Clicked()

command

command->Execute()

MenuItem-Command Relationship



• A command may delegate all, part, or none of the request’s implementation to other objects

• This is perfect for Lexi that must provide centralized access to functionality scattered throughout the application.

User Operations: Command Pattern

Command Pattern

The Command pattern objectifies the request for service. It decouples the creator of the request for a service from the executor of that service.



Spell Checking and Hyphenation


• Encapsulating Traversal

• Traversal versus Traversal Actions

• Design Patterns: Iterator & Visitor Pattern



• The design problem involves textual analysis:– Checking for misspelling

– Introducing hyphenation points where needed for good formatting.

• Constraints are similar to the formatting constraints

• Two pieces of the puzzle:– Accessing the information to be analyzed

– Doing the analysis

Spell Checking and Hyphenation: Goals and Constraints



Spell Checking and Hyphenation: Traversal vs. Traversal Actions

Command

Execute()

NullIterator

First()Next()IsDone()CurrentItem()

iterator

return true

Iterator Class & Subclasses return new NullIterator

ListIterator


ArrayIterator


PreorderIterator


currentItem

Glyph

...CreatorIterator()

root



Iterator Pattern

Iterator Pattern objectifies traversal algorithms over object structures.

Visitor Pattern

Visitor Pattern centralizes operations on object structures in one class so that these operations can be changed independently of the classes defining the structure.

Spell Checking and Hyphenation: Iterator & Visitor Patterns



Summary

• Eight different patterns applied in the Lexi’s design:

– Composite to represent the document’s physical structure

– Strategy to allow different formatting algorithms

– Decorator for embellishing the user interface

– Abstract factory for supporting multiple look-and-feel standards

– Bridge to allow multiple windowing platforms

– Command for undoable user operations

– Iterator for accessing and traversaling object structures

– Visitor for allowing an open-ended number of analytical capabilities without complicating the document structure’s implementation



Discussion QuestionsDiscussion Questions

1. Define: Glyphs and Monoglyph

2. List the goals and constraints of:

Formatting

Support multiple look-and-feel standards

User operations

Embellishing the user interface

3. Explain how to achieve the goals for formatting

copyright © 1995-2004 active frameworks inc. - all rights reserved - v2.0document editor - page...

Documents