kdom and khtml integration

[Nikolas Zimmermann]

Hi Andras,

> A little. In short, we want to have in Quanta a common DOM tree for source
> and VPL (WYSIWYG) mode. Right now we have our own tree and there is the
> KHTML DOM tree. This requires intensive synchronization between the two
> whenever the document is modified in source or VPL mode. With KDOM we
> wanted to solve this problem, and can you tell me if this will be possible?

> What I was thinking is:
> - parse the document with our own parser and create a KDOM based tree
Hm, you probably need to parse additional stuff like PHP etc? Can you
elaborate a bit more, how you reuse khtml's parsing/tokenizing in Quanta?
(do you use it at all? or do you build two completely seperated trees)

> - the KDOM tree nodes must be extensible (they should be able to hold extra
> information)
That will definately be possible, just like the NodeImpl contains pointers to
the RenderObject, we can also supply nodes with "UserData".

> - KHTML should be able to render directly this KDOM tree (for VPL mode)
If you want _one_ tree, then you need to let the html parsing/tokenizing
create the tree. A custom parser can't help there?

> - it should be possible to modify the tree from code, without regenerating
> from scratch
That is definately possible.

> Now if all the above will be possible even with this monolithic design, I'm
> fine with it. Like Paulo said, we just want to have a KHTML and the
> underlying DOM tree which will make developing WYSIWYG application easier,
> without requiring extensive and ugly hacks.
Well the monolithic design doesn't mean at all that "kdom is gone". It just
lives in a new directory called "khtml", and it's main benefits will still be
existing. At least that's our plan. :-)

I'll promise to check out Quanta code myself after tomorrow (last exam!).
That should help my understanding of your problems a lot :-)

Bye
 Bye
  Niko