Subject: fields design -- assumptions
From: Paul Rohr (paul@abisource.com)
Date: Fri Sep 22 2000 - 19:43:10 CDT
FYI.
Here are the assumptions I used when working on the fields design earlier
this summer:
I. Use the same file format for all fields. The arguments can vary as much
as needed, but we should use the same attribute name iff the concepts are
semantically equivalent.
II. Field contents are editable and participate in undo actions. For
details on the desired interaction behaviors, see:
http://www.abisource.com/mailinglists/abiword-dev/00/June/0233.html
III. Although some piece table changes are likely, they shouldn't be that
extensive. All knowledge of the semantics of particular fields (and their
attributes) should be encapsulated outside the piece table. The piece
table's job is just to reliably import/export and handle editing and undo
via the various inbound (Document) and outbound (Listener) APIs.
IIIa. Undo is the hidden orphan of this design space. Favor solutions
which make seamless undo/redo behavior easy to implement reliably.
IV. Breaking file format compatibility with the existing FIELD hacks is OK
if we have to, so long as we do it before 0.9.0.
IVa. If so, it'd be polite to have an easy way to do the conversion.
IVb. However, I'm leery of leaving compatibility code in our importers
over the long term. I respect Eric Bina's work tremendously, but I don't
want to follow his precedent in the word processor world.
V. If we can't eventually express *every* field defined in the RTF spec,
then our mechanism isn't general enough.
Va. It's fine to postpone most of those implementations, though. For
example, we'll need to add a bunch of code for style and section editing
before we can consider adding TOC support, which sounds entirely out of
scope for the 1.0 timeframe. (Unless Bruce decides to quit his day job.)
;-)
Vb. However, it would be a Bad Thing to knowingly take a shortcut now
which will force us to go through outrageous gyrations (or worse, break
file format compatibility) to implement additional fields later.
VI. And finally, my favorite design principle always crops up -- KISS. If
done right, our generic fields implementation really shouldn't have to be
all that complex.
Paul
This archive was generated by hypermail 2b25 : Fri Sep 22 2000 - 19:36:32 CDT