Subject: Re: design -- ASSERT(field is a container)
From: Justin Bradford (justin@ukans.edu)
Date: Fri Dec 24 1999 - 15:42:38 CST
> In essence, I'm rapidly coming to believe that the FIELD tag should become a
> container which surrounds the last calculated text for that field, with a
> richer set of XML arguments which can be used to update that calculation
> when needed. For example:
>
> Now the <field ... >last text used</field> gets marked up differently.
>
> I haven't dug much more than this, and don't have a proposed syntax, but
> wanted to at least raise the issue for discussion.
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.
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.
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.
Justin
This archive was generated by hypermail 2b25 : Fri Dec 24 1999 - 15:42:40 CST