On Friday 10 June 2011 08:56:06 Jos van den Oever wrote: > On Friday, June 10, 2011 08:43:58 AM Pierre wrote: > > That is a really interesting solution. The biggest trick would be not to > > forget to delete the objects at the right time if the endElement stays in > > the destructor. > > But I'm not sure how it would interact with the change tracking code, > > unless you can integrate change tracking in these classes, then it's just > > great... > > The change tracking is a touch nut to crack indeed. I cannot oversee the > implications there. In my opinion, change tracking logic should be separate > from normal serialization. TC code would need to write fragments. So the > change tracking writer can also be a friend of the classes it needs to > write. > > Would that be enough or are there more problems? Can you give an example? > > Cheers, > Jos I'm sorry I don't know the change tracking enough to provide illustrations. At least in Kotext, it is quite complicated, far from separate from normal serialization. Looking at the code is hardly enough to understand what is change related and what is not...
Also, another question about your proposal : would it be strict regarding the content types ? I mean : a positiveInteger attribute for a given node must remain a positiveInteger, and that could even be checked at compilation time...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
