[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Review Request: Enable the modification of KoXml DOM tree
From: Thomas Zander <zander () kde ! org>
Date: 2010-02-27 14:03:59
Message-ID: 201002271504.00009.zander () kde ! org
[Download RAW message or body]
On Saturday 27. February 2010 07.16.40 Ganesh Paramasivam wrote:
> As you can see, these rules actually imply a modification of the DOM. We
> already have a working code for loading delete changes which does not
> require a write-able DOM tree. But the code would be a lot more cleaner
> with a write-able one. Hence this change.
Hmm, this is a double-edged sword. While the changetracking may get cleaner
I'm no fan of breaking abstraction levels.
The assumption that while loading the DOM stays unchanged is a really useful
one to avoid a lot of debugging. It is also a useful one to allow memory
consumption optimizations and speed optimizations.
In other words; while I trust you are right that the changetracking loading
gets more complicated, your change breaks the assumptions of loading and that
has the long term potential to make a lot more problems.
I'd like to know what others think, is this a tradeoff that is worth it? Does
this concept change make things (ODF) loading harder to maintain?
I'd personally thing its best to go for the change-tracking loading doing a
second pass and thereby limiting the impact of this complexity to one nice-to-
unit-test place in the code.
--
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic