[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] parser in Quanta
From:       Andras Mantia <amantia () kde ! org>
Date:       2006-01-16 21:49:22
Message-ID: 200601162349.22969.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 16 January 2006 16:40, Jens Herden wrote:
> Hi Andras,
> yes in deed, QXmlReader is only parsing valid code. But my suggestion
> was not to use QXmlReader ;-)

Well, KDOM seems to be able to use two parsing backends: libxml and 
QXml. The latter is using QXmlReader or a derivate class from it.

> I wanted you to look into this to get an idea what kind of parser I
> want to have and I knew that we can not use QXmlReader. But the whole
> structure around QXmlReader with reader and builder is worth to copy,
> I think.

Might make sense. But I think the accent is on copy. Or maybe can be 
used as a source of inspiration.

> So my suggestion was, like you said, to create our own 
> QXmlReader derived class which is very error tolerant and fixes as
> many problems as possible to get a useable KDOM tree for the
> renderer.

Still I'm not sure what we can get from it and if it is possible to 
integrate with KDOM in the way they intended or we just have to use 
hack after hack.


> >  The real problem is parsing only part of the document and merging
> > it with the existing DOM tree. Jens asked we if parsing the whole
> > document always is slow or not. According to my previous testing it
> > was very slow with the current parser and I don't except much
> > better results with any new one.
>
> I do expect better results :-)

But how much better? I doubt it will be 2x, not talking about the 5-10x 
we would need... 

> >  So I think we need partial parsing and merging with the existing
> > DOM tree and I don't see a solution with QXml or KDOM.
>
> Where exactly do you see the problem to feed parts of documents into
> the parser and merge the resulting tree with an existing one?

I could not see a way with QXmlReader to parse only a part of the 
document. Merging has to be done by us anyway.

> >  There is another problem with QXml: it requires an IODevice, a
> > ByteArray or a QString a a source.
>
> AFAIK this is not correct. What we need is a QXmlInputSource and what
> QT offers uses IODevice or Byte Array. But I think we can create our
> own QXmlInputSource that operates on a KTextEditor interface somehow.

We might try to subclass it.

> > - when creating/manipulatin nodes, call a helper class to create
> > nodes - this helper class will create whatever nodes we want (our
> > own or KDOM nodes)
>
> This is what I would call the builder :-)
> If we could use the existing builder for KDOM we could save some
> work.

But as KDOM is not yet available and I have some doubts about the 
possibility to fit clearly for our case (unless someone proves me 
wrong), I would suggest to completely write our own code.
>
> > - write our own code to detect the changed areas and reparse it and
> > merge the DOM trees
>
> This is the point that could become hard from what I know in the
> moment. But I see no real blocker here.

If it is possible to insert nodes in whatever position you want, or to 
move nodes (and their children), then it is doable.

> So still the question how to proceed? We can not use KDOM2 yet and
> creating our new parser with our custom dom tree was the last idea.
> Do you still want to go this way? 

Yes, but in a way that our custom DOM tree can be easily replaced by 
KDOM once we switch to Qt/KDE4.

> I am not so sure anymore, because I 
> fear that we make a lot of work that will be thrown away when we
> switch to KDE4.

We don't have to throw that away. KDOM is needed for VPL, but as I 
understood it will be really useful only if KHTML is based on KDOM as 
well (which is currently not). So I suggest to make a clear 
architecture and code for parsing and tree building. The rest is 
detail. ;-)


Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]