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