|
|
|
|
Box Structure
|
|
The API cross references
give an immediate access to relevant interfaces and classes.
|
|
Box Structure
We make no distinction between composite objects and
leaves. The
glyph
concept is a key one as it acts as the fundation of the
composite structure. A node of the whole-part hierarchie
knows about its parent and children. On the other hand
leaves
require a specific attention.
Here is our
position
on safety and transparency in composite.
|
|
|
|
Atoms
Atoms are the leaves of the
box structure .
They do not have children and provide the basics
of formatting and drawing tasks. As an application may
use many of them, their storage cost is really sensitive.
The naive design (unshared atom) is well suited for
unusual terminals. When you think in term of key-word
then you should use instead the DecoratedSharedAtom.
Here are some implementation issues relative to
text
drawing in java
relevant to the design of atoms.
|
|
|
|
For common use, the shared atom is the only way to deal
with big structure. To do that, each objet shares
as much as possible of its state. The extrinsic part
(origin, parent, ...) can't be share, but the intrinsic
part (text and size) is stored in a flyweight.
A flyweight registry maintain a list of all shared
flyweight. We use reference counting to remove unused
objects. When formatting a shared atom, first we ask
the registry for the given value (string or character
code) in the given font before allocating a new one.
|
|
|
|
Updates
The box structure updates are made through the
visit of a modification
path.
The path building visitor is used during the building
stage. The mark stable/mark unstable operation allows
the synchronization
of the formatting and building threads. The
path modification visitor is used during the interactive
updates. This visitor computes the damaged area
from removed or replaced boxes. The boxes are also
tagged for
incremental
formatting.
The available Operations are :
- inserting a new child
- removing a child
- replacing a child with a new glyph
- marking a glyph as stable (i.e. ready for format)
- marking a glyph as unstable (i.e.e not ready for format)
|
|
Glyph
A glyph is an abstract notion representing all objects
that we manage in a document. They know how to
draw themselves,
how much space they need,
their relationship with their
parent and children ,
how to interact
with the user and
how to manage exceptional situation.
Also a glyph knows how to manage its origin, its size, its
format status
its modification
tag. As the size is a
computed value,
a glyph could manage a dependent (i.e. an object that
needs to be notified when the size changes)
and provides access to the
current size value, to the accurate value (eager value)
or lazy value (accurate value if there is no previous
old value).
|
|
|
|
The main point is to maintain the components as small as
possible since each attached information could have a
major impact on derived classes. Heavy used concrete
classes likes atoms
share extrinsic information like size and datas.
|
|
API Cross References
- Interfaces:
- Classes:
- Exceptions:
|
|
|
|
|
|
|
|
|
|