Subject: fields design -- separate endStrux() APIs??
From: Paul Rohr (paul@abisource.com)
Date: Sun Sep 24 2000 - 03:58:43 CDT
The existing PT design presumes that all strux of a given type are adjacent
to another strux of the same type, so you can use very simple leftwards
lookups to reconstitute the imported document hierarchy.
Fields are our first "non-adjacent" container, which require us to keep
track of both the begin and end points explicitly in the piece table. We're
getting away without API mods because we're "hiding" that complexity behind
PTX_FieldEnd.
If, however, we want to generalize the "end strux" handling so we can later
use it for other non-adjacent containers in the file format, then we *will*
need to widen one or more of these APIs to pass a bit more information.
instead of we could do something like
---------- --------------------------
appendStrux(PTX_FieldEnd) endStrux(PTX_Field)
insertStrux(pos,PTX_FieldEnd) endStrux(pos,PTX_Field,sdh)
Thew idea would be that instead of creating another strux subtype
(PFT_Strux, PTX_FieldEnd), we could have another frag type (PFT_StruxEnd,
PTX_Field).
A change like this would probably simplify the piece table implementation in
spots -- especially _getStruxOfTypeFromPosition() -- but I'm not sure it's
worth it, at least now. In particular, I believe that to pass enough
information to make undo work, we'd also have to widen the PX_ChangeRecord
and PL-Listener APIs accordingly, and that sounds like overkill.
Of course the final decision here is up to whover does the implementation,
but off the cuff I'll stick to my recommendation that we not introduce this
level of generality until we know we need it.
Paul
This archive was generated by hypermail 2b25 : Sun Sep 24 2000 - 03:52:04 CDT