Subject: clarifications on changing how fields work
From: Justin Bradford (justin@ukans.edu)
Date: Sun Mar 12 2000 - 00:11:27 CST
We need to make fields containers, but how versatile of containers
do they really need to be?
1. Will it contain text other than (previously) generated field text?
2. Do we need to encapsulate other fields in the container?
I would prefer a no to both questions.
For one, it just doesn't make sense to have user editable text inside
field generated text.
For two, the only time I've seen this happen is Word is in the field
definition (ie. referencing other fields, which we'll do in the field
attributes, not in the enclosed text section) and for equations.
And equations, IMHO, should defintely not be done like Word's equation
fields.
So, I think fields should only contain the generated field text, such as:
<field type="creationtime" format="MM/DD/YYYY">03/11/2000</field>
Again, referencing other fields (for non-scripting purposes, as that will
be done in a sane, non-Word way [ie. actual scripting]), would occur like:
<field type="mailmerge"
format="User $data1 is cool"
data1="field.namelist.value">Joe is cool</field>
Agreed?
If so, then here's a quick proposal on how things (specifically import and
piecetable) would be changed:
Rather than turn <field> into a Strux fragment, we add a label property to
the Object fragment. Then, we change the importer for object types (field
and image) to work more like the data item. we don't append the object
immediately; instead, we gather all of the contained text into a temporary
buffer, and then, when we hit the end element, we append the object with
one extra agrument: the contained text.
This has the added cool effect of allowing us to put labels on images,
which might be used as an alternate display method (ie. instead of
actually showing the image, show the text label) like with web browsers
and the alt attribute on images.
It also requires only minor changes to the importer and the piecetable.
Also, in case anyone is wondering, you get an end element callback with
<image/> as well as <image>Graph of revenues</image>, so one could use the
old style, single tag, or the new style container with a label.
Now the text in this label would render with the same surrounding format
tags.
<c props="text-weight:bold"><field type="time">11:32 PM</field></c>
The above would be a bolded date.
Drawbacks: the user cannot edit (either insert/remove text) or change the
formatting properties of subregions of a field. So one could not bold just
the AM/PM part of a time, for instance.
Word lets you do this, but when you update the field, all the changes and
formatting are lost (for the most part; the version I tried it on appeared
to have a bug which caused some of the properties to remain on the end of
the field, sometimes).
I can see some purpose in allowing formatting, but it would be difficult
to accomplish consistently for the sake of the user. For example, one way
to do it would be to remember that formatting spanned x number of
characters at offset y, but that might lead to:
<i>12</i>:30 AM
...
<i>1:</i>30 AM
Dates (or changing between languages) is even worse.
However, to someday accomplish this right, we could assign formating to
subparts of the field. This would not happen in the contained text, but in
the format attribute.
so:
<field
format="{props=text-weight:bold}HH</props}:MM {props=text-style:italic}AP{/props}"
>...</field>
rather than:
<field format="..."><c props...>HH...</field>
Telling the formatter that info would be encapsulated down in the FieldRun
object, and theoretically, the UI could be just like normal, except the
FieldRun stores it (ie. select the text, click the italic button, and the
Field object gets this event and updates its format accordingly).
Doing it the other way just doesn't make sense to me, unless we consider a
whole new approach to fields (such as embed the "guts" of the field format
inside the field container), ie.
<field><c>HH</c>:MM <c>AP</c> random user text!! </field>
That, however, would have profound impacts on the current piecetable, at
least from my understanding of it. Field becomes a new Strux (like a
Block) where various bits might be dynamically updated/replaced.
I imagine it's probably massive overkill, too, especially if we implement
a bit of style formatting ability into field formats (which might also be
overkill...)
After settling this stuff, the changes to the formatter FieldRun object
isn't too bad. A minor change to _doInsertFieldRun in fl_BlockLayout,
a static constructor for fp_FieldRun (which _doInsertFieldRun calls
instead of 'new'ing it's own fp_FieldRun), and the implementation of field
functionality as subclasses of fp_FieldRun (which the static constructor
actually creates, rather than a generic fp_FieldRun).
Anyway, I thought I'd throw this out so we can settly the details and get
to implementing the changes.
Justin
This archive was generated by hypermail 2b25 : Sun Mar 12 2000 - 00:11:30 CST