Hi Oliver, thanks for the feedback.
Regarding the <field-start/>, <field-end/> (which is my favorite too) there seems to be some resistance, e.g. from Svante who dislikes it, 'cause XLS(T) processing gets worse... The other thing which bothers me are operations like copy/paste. I tried to use bookmarks to simulate fields but had enourmous problems implementing operations like copy/paste. However I agree generic start/end would be cool. My idea to implement a real generic field would end up having the current SwDoc to be somehow virtual. I.e. you have to SwDocs. Maybe this will help us for change tracking too. Makes sense? ~Florian >>> Oliver Specht - Sun Germany -Hamburg <[EMAIL PROTECTED]> 02/14/07 3:04 PM >>> >>> Hi Florian, Florian Reuter wrote: > Lessons learned from field prototypes and WW doc analysis > > Needed: > > a) Field need be considered for line break. > > b) Fields need traversable. > > c) Fields need to be nestable > > > Optional: > > d) Fields must be able to cross paragraph boundaries. > when we do something with our fields we should not stop half-way. Fields should be able to include everything that a document body can contain. They should be able to start inside of paragraphs and end inside of paragraph. How else should we be able to implement fields that resolve file links or expand AutoText blocks? > Additionally this would prevent <field-start/> and <field-end/> marks in ODF > :-) However I way result in slightly different layouts. > The way these new fields will be specified in the file format does not influence the implementation. Although I like the field-start/field-end approach. ODF already uses a similar approach for bookmarks. Why shouldn't that work for fields? > At the end I would prefer to reuse the existing field mechanism and simply > enhance the layout code such that a) fields considered for line break and c) > field texts can also contains field wildcards. This again has to be > considered by the layout code. > There's no need for the layout to change. Field content is nothing else than normal content. > Regarding b) I would like to introduce a special field edit mode”, similar to > the XForm edit mode. > > The idea: > We add an additional SwNode array to a SwDoc or reuse one of the existing > areas. We introduce a new special “field wildcards” which references an > SwNode. > Sorry, that sounds like an ugly hack to me. > We enhance the layout such that these new field codes are recognized and that > the text is loaded from the SwNode. > By having the text of the fields stored in SwNodes we can place a cursor to > it :-) > Having fields as start/end marks in the document allows cursor travelling without implementing one additional line of code in the layout or in cursor travelling. Regards, Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
