Subject: Re: chunks design -- ...
From: Paul Rohr (paul@abisource.com)
Date: Sun Sep 24 2000 - 04:25:12 CDT
Martin,
Which patch are you referring to? The last code I remember seeing from
Keith was followed by a lengthy exchange between Keith and Justin where they
agreed that certain aspects of that code should morph into something a lot
more like what I've been describing.
At 12:12 PM 9/24/00 +1000, Martin Sevior wrote:
>1. Do we really want to allow editting of Fields?
Of course. The only question is when.
>This adds a whole of
>complexity if we want to preserve editting of fields through field
>updates.
Huh? I thought the whole idea of updating a field is that you completely
*replace* its contents.
>My example is TOC. If a user decides to change on line of the TOC
>it will be very hard to preserve this change when she adds a new chapter
>and the TOC is updated.
TOC is a tricky example, because it's a chunk which contains a lot of other
fields -- specifically page and document references. Note that there are
(at least) two different kinds of UI-driven updates to a TOC:
- cascading update for just the embedded fields
- regenerate the entire chunk from scratch
I suppose that the first operation might preserve edits to the contents of
the TOC chunk (depending on whether they modified an embedded field or not.)
However, the whole point of doing the second operation is to get rid of all
those edits, isn't it?
>2. Is a chuck a subclass of a fl_BlockLayout? I'm not convinced we need
>it. Can you give me an example of where Kevin's code will fail to give us
>the Field we want?
Feel free to ignore chunks for now. We should only worry about getting a
robust implementation for so-called fields which do NOT allow embedded
paragraph or section breaks. These fields are small, localized containers
which live "inside" a containing block. For most purposes, the formatter
can entirely ignore the fact that certain runs are inside a field.
For stuff like TOC which generates a large chunk of content -- lots of
paragraphs or even an entire section -- we'll need a separate mechanism.
The chunks are at document scope, and are essentially orthogonal to our
existing section/block hierarchy. (They can easily violate nesting,
remember?)
If you're thinking class hierarchies inside the formatter, both Field and
Chunk could probably be subclasses of a common GeneratedContent class. For
the most part, the field and chunk objects are external bookkeeping off on
the side which control the regeneration of that content, if needed.
When you're down at the line and run level, you rarely need to know that
you're inside a chunk or field, and when you do, you can go look it up if
needed.
Is this making sense yet?
Paul
PS: However, it might make the implementation a bit easier if we subclass
these off fl_Layout, just because it makes the handle exchange with the
piece table easier.
This archive was generated by hypermail 2b25 : Sun Sep 24 2000 - 04:18:34 CDT