Subject: Re: fields design -- FIELD is a strux
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sun Sep 24 2000 - 18:33:35 CDT
On Sun, 24 Sep 2000, Paul Rohr wrote:
<snip>
>
> - 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)
I'm not sure we need strux's. My main concern is my lack of knowledge of
how a new strux would map to the layout classes. Would we need a
fl_FieldLayout class like a fl_BlockLayout? That sounds like a horrendous
amount of work.
Especially since Keith's field as a fragment seems to work fine.
>
> In addition, the existing field-as-atomic-object hacks can all be removed
> from both the piece table and the formatter.
>
I like the inline fields. See my other post.
> 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?
>
I'm concerned that this is too much work for no enough reward. If we can
build a TOC within a Block I don't see that we need a Field strux. Other
more complex uses of fields can be implemented via scripting.
Martin
This archive was generated by hypermail 2b25 : Sun Sep 24 2000 - 19:32:09 CDT