Subject: Re: clarifications on changing how fields work
From: Keith Stribley (keith@stribley.dabsol.co.uk)
Date: Sun Mar 12 2000 - 09:33:03 CST
Justin Bradford <justin@ukans.edu> writes:
> 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>
>
Yes, I think this looks good. How would you handle the "if" type fields?
Would it be:
<field type="if" format="$bookmark1.pagenumber=1" bookmark1="firstpage" true="equal" false="not equal">not equal</field>
>
> 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.
>
I've started on an alternative, see below.
> 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.
>
The idea of allowing labels for images sounds good.
> 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 disagree about the scale of the impact. I've started work on implementing fields by getting an pf_Frag_Object to create fp_Frag_Text objects to represent the text which then converts to fp_TextRuns, fp_TabRuns etc. The advantage of this is that all the text formatting stuff is handled already by the text runs without having to rewrite it specifically for fields. It just requires a modification to allow runs to be linked to fields and to stop the user modifiying them and colour them grey in this case. As the more fields get implemented the ability to insert Tabs etc as part of the formatting would be very usefull, eg. for Lists. Table Of Contents will have to use the full range of runs to represent their contents.
In this scenario fp_FieldRuns would disappear (or maybe just be used for displaying the arguments to fields when chosen by the user).
I am still using a pf_Frag_Object which creates a Field class (or subclass) which handles the logic to update the field and links to the current field text in the ut_GrowBuf. (See my earlier mail on how such subclasses might work and be updated). The pf_Frag_Object has no visible representation in the document, it is the fp_Frag_Text objects it creates which give rise to visible runs.
At the moment, my modifications are in the early stages and not ready for a patch yet. However, they are representing formatting with <field><c> </c></field> when exported. Only a minor modification was needed to the exporter since it already knows how to handle fp_Frag_Text objects' formatting. When a px_CR_Object is found <field> is inserted. The test is then inserted as if it was user text. As soon as a Change Object is found without a pointer to the Field object a </field> is inserted. At the moment the user can individually format parts of the field, but it is lost at update. I agree this is undesirable, but could be got around in the same way as you describe for output. It could just be extracted from the fp_Frag_Text before the next update.
> 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).
>
My main objection to this is that it is very restricting to have a field represented by a single run object. As I understand it text wrapping is done by splitting two fp_TextRuns. Any field with more than one word eg: a reference to a document title or comment, will need the ability to wrap. It would therefore be simpler to allow reuse of all the wrapping code by representing the contents of fields with fp_TestRuns just modifiend to prevent editing. May be I've completly misunderstood the code, but no one ever got back to me either way on it.
Let me know what you think before I go too far along the line of implementing my suggestion. Unfortunately I'm not finding much time to work on it at present.
cheers,
Keith
-- Keith Stribley http://www.stribley.dabsol.co.uk/
This archive was generated by hypermail 2b25 : Sun Mar 12 2000 - 09:43:55 CST