Subject: Re: A start at the new field implementation
From: Paul Rohr (paul@abisource.com)
Date: Fri Mar 24 2000 - 00:28:14 CST
At 11:55 PM 3/19/00 +0000, Keith Stribley wrote:
>As promised, here are my efforts so far. As yet they are not very
>impressive, but hopefully it shows the idea. The example abw file shows a
>test field using pf_Frag_Text. This currently still uses objects as a place
>holder in the field table, rather than a strux replacement.
Keith,
This is a really promising start. I assume from the tone of your message
that we should hold off on adding this code to the tree until it progresses
a bit further. Still, it's very nice to see how far you've gotten already.
>The following features seem to work:
>Text wrapping in the middle of fields
>refusing to allow users to type in the middle of fields
>only allowing the user to delete part, rather than a whole field
Excellent.
>The fields can be written in abi format and read back, though the old value
>of the field is currently junked and recalculated (arguably this should
>remain the case, it gives a higher chance of wrongly calculated fields
>being corrected).
Another option would be to put up a field-specific context menu allowing the
user to trigger a manual update as needed.
More specifically, I'm assuming that the appropriate update policies will
vary on a field-by-field basis. The old code assumed that all fields get
updated pretty much continuously -- on every cursor motion, in fact -- which
is probably only appropriate for a very few fields, such as:
current Date/Time
total page numbers (perhaps)
For example, the following fields all get updated by a specific event:
PrintDate
SaveDate
etc.
Others never get recalculated:
CreateDate
>There are several issues still to be addressed:
>The old fields are still left in, only a new (and temporary) "test" field
>type is implemented showing the new mechanism.
How did you manage that? I thought the way the import code used expat we
had to either have fields as a container or not.
>Updating - at the moment updates are only called on reading in or after
>undo's.
See above.
>Undo's on fields - these sometimes throw ASSERTS in the spell checking code
>(esp after applying formating - possible fields shouldn't be checked
>anyway, but this isn't implemented.
There's a known problem with spell checking near block boundaries, but
you're probably seeing something different.
>Currently field updates create change records - is this desirable? As a
>side effect it means than updates musn't be called in the middle of an undo
>as an infinite loop will result - it can never get back to the old state
>due to the updates.
It depends. I can think of at least 3 ways field contents would change.
(There are probably more.)
1. Automatic updates probably don't require an undo. Unless someone wants
to mess with the laws of physics, hitting control-Z won't ever allow users
to roll back in time and recover a previous value for the "last printed"
time. That document was printed (or saved or whatever) and you can't undo
that.
2. However, I suspect users might want to undo a manual update. I'm not a
big user of fields, so it's kind of hard to think of a use case.
3. Clearly, any changes which got triggered via editing operations
(deleting, formatting, etc.) should be undoable, just like they are outside
of fields.
>Implement real fields! - create subclasses under the new fd_Field class to
>handle different types of field and do something useful.
Yep. As soon as we get all these plumbing issues snaked out, we ought to be
able to have lots of people implementing various field subtypes in parallel.
>I'm about to go on holiday for a couple of weeks, so I pray this doesn't
>cause too many problems.
Have a great time. :-)
Paul
This archive was generated by hypermail 2b25 : Fri Mar 24 2000 - 00:22:51 CST