Subject: Re: design -- ASSERT(field is a container)
From: Paul Rohr (paul@abisource.com)
Date: Wed Jan 12 2000 - 19:49:25 CST
At 03:42 PM 12/24/99 -0600, Justin Bradford wrote:
>I'm not sure if I mentioned it before, but Word does a similar thing. Part
>of their fields have the "instructions" to generate field text, and the
>other part is the most recently generated text.
Good. That's more confirmation that we're on the right track.
>Also, as for what goes inside <field ...>, it will need to be pretty
>flexible. In Word, at least, there are many options, flags, format
>descriptions, etc. They use a backslash tagging thing like "\e \f mm:hh:ss
>\w" to describe their fields.
>
>Our field tag will probably need at least a "type" and "format" element.
>Maybe an "option", too. The usage of format/option would vary depending on
>the type. I'll present a detailed list of some Word field
>properties/options so we can make a more specific format.
Thanks. That enumeration will be very helpful.
>And finally, the code for handling field runs: Rather than just a field
>object which has the logic for all the fields, we might want to have
>subclassed field objects (as there are several fairly distinct groups of
>fields, and many fields within each group). The piece table would call
>some field factory which would create an appropriate field subclass, and
>then the piece table could still just think of it as a generic field for
>rendering purposes. Each field subclass could handle similar groups of
>field types, but if all of the code was lumped together, it could become
>a large file.
In the formatter, it might be worth having lots of different fp_FieldRun
subclasses, each of which has their own logic for handling specific kinds of
fields. However, at the Piece Table level, it sounds a lot cleaner to have
a single field data structure (arguments plus contents).
Is that what you had in mind?
Paul
This archive was generated by hypermail 2b25 : Wed Jan 12 2000 - 19:44:06 CST