fields design -- FIELD is a strux


Subject: fields design -- FIELD is a strux
From: Paul Rohr (paul@abisource.com)
Date: Sun Sep 24 2000 - 03:15:21 CDT


The following discussion presumes that FIELDs are not CHUNKs, and use a
content model and markup as described here:

  http://www.abisource.com/mailinglists/abiword-dev/00/September/0268.html

Basically, after all my digging around, I've realized that I agree with the
conclusion reached by Justin and Keith back in March -- as far as the piece
table is concerned, fields should be implemented as strux:

  http://www.abisource.com/mailinglists/abiword-dev/00/March/0254.html

What we wind up with (more or less) are the following additions to the
0.7.11 codebase:

  - slight modifications to the import/export code
  - extra X_CheckDocument integrity constraint...
    ... either _getFieldDepth() if nested, or just m_bInField

  - PTX_Field
  - PTX_FieldEnd (or PFT_StruxEnd, if feasible)
  - the associated pf_Frag_Strux subclasses

  - a collection of ff_Field objects hanging off blocks
  - logic so runs can find their associated fields (cf: squiggle)

In addition, the existing field-as-atomic-object hacks can all be removed
from both the piece table and the formatter.

Note that unlike the other existing strux types, fields aren't necessarily
adjacent, so there will need to be some additional logic to skip over
matching End objects when looking for the containing PTX_Field:

  pt_PieceTable::_getStruxOfTypeFromPosition()

It might be a little easier to see how the mappings work if we compare how a
simple document gets represented in each of the three areas:

  markup attr? pt frag types formatter
  ------ ----- ------------- ---------
  <section> opt PFT_Strux, PTX_Section fl_SectionLayout
  <p> opt PFT_Strux, PTX_Block fl_BlockLayout
  ... no PFT_Text fp_TextRun
  <field> yes PFT_Strux, PTX_Field ff_Field
    ... no PFT_Text fp_TextRun
    <c>...</c> yes PFT_Text fp_TextRun
    ... no PFT_Text fp_TextRun
  </field> no PFT_Strux, PTX_FieldEnd (implied)
  ... no PFT_Text fp_TextRun
  </p> no (implied) (implied)
  </section> no (implied) (implied)

Note that since we're implementing fields as strux, we can use all of the
usual tricks with StruxFmtHandle and StruxDocHandle to exchange information
(for a given field) back and forth between the formatter and the piece
table.

Is this making sense so far?

Paul



This archive was generated by hypermail 2b25 : Sun Sep 24 2000 - 03:08:49 CDT