[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 () kdewebdev ! org>
Date:       2006-01-18 9:33:47
Message-ID: 2203.84.247.48.241.1137576827.squirrel () mail ! kdewebdev ! org
[Download RAW message or body]

Hi Jens,

 My wife is working on my main computer, so I reply without being able to
verify everything in the documentation, but due to the time difference, I
want to get an answer today, so I write down my thoughts now.

> Actually my wording is not precise. What I really meant was to use a
> QXmlReader derived class to have the possibility to plug it into the KDOM
> builder.

Ok, I have to ask now how the builder/parser mechanism works in KDOM as it
is not clear for me. In my mind a parser is called by the application and
it builds a tree. I don't see the connection in the other way around, so I
don't see why cannot we use our own whatever parser with KDOM.

>> 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.
>
> We are in the process of evaluation. How can we find out more about this?

Well, we can try to implement, but would be a waste of time if we spend
some weeks in something we will throw out later. So if we start to work on
the parser, I would like to do in a way we are sure it will work.

>> I could not see a way with QXmlReader to parse only a part of the
>> document.
>
> Where is the problem here? We have find a smart way to detect which part
> of
> the document is damaged and only feed this substring into the parser. I
> think
> it is not much different from what we have now.

Does it really work that way? I read something about when it detects the
end of a document or the end of the file. It seemed very document/file
specific. But it *might* be that what I remember was the simpleparser.

>> > 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.
>
> Can you please elaborate more on your doubts? Especially after reading
> Frans
> mail.

First as I said it is not clear how the builder from KDOM works and how
can we benefit from it. Secondly, even Frans said it is not yet decided if
KHTML from KDE4 will be really KDOM based or not. I hope it will, but as
the current trend is to keep webcore and KHTML in sync, this is something
that might be decided not only by the KDOM developers, but by Apple as
well. Yet, I am maybe even more clueless than Frans is. And if KHTML does
not use KDOM, we will still have two 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.
>
> I assume that any DOM tree has this ability. Where comes your suspicion
> from
> that KDOM can not do it?

No suspicion, I just think loudly. I'm sure it is possible to do.

>> Yes, but in a way that our custom DOM tree can be easily replaced by
>> KDOM once we switch to Qt/KDE4.
>
> Here are my concerns. I think it is not good to invest a lot of work in
> our
> custom DOM tree.

I don't see how much we have to invest there. The nodes exists, the only
thing we have to do is that implementation-independent builder class.
Once we switch to KDE4 and can use KDOM, it is about calling KDOM's
methods instead of ours. Isn't it so?

> From my POW there are two ways to go: Either we can reuse
> most of the DOM tree we have yet or we should postpone the work on the
> parser
> to KDE 4 in order to use KDOM from the beginning.
You were the one who said we should do the parser asap, and right now I
agree with you. Unfortunately switching to KDE4 is still not a real
option.
Of course we can do other things in KDevQuanta, but right now I am very
interested to work on the parser, especially if you have time as well, so
I don't have to do it again alone.

> very likely that this will be KDOM. So we could start a discussion about
> this
> in k-core-dev to make sure this will happen.

We might ask, but I'm very sure the response will be "we don't know yet".

> But this is the future. What we have to decide now is what to do for a
> Kuanta
> release.

Right.

> From my current understanding the clear architecture should be:
> 1. create a reader that operates on a texteditor
> 2. create a tag soup parser
> 3. create a builder that builds our current DOM tree so that we can reuse
> the
> rest of the code. This builder should implement the builder interface of
> the
> KDOM builder.

Yes, this is what I said.
>
> Partial parsing is optional for me for this testing release. We probably
> need
> it for KDE 4.

I'm sure that you will find non-optional after the first test.

So, I suggest to design the builder and inputsource classes. If you think
it is good for us to derivate them from the QXml* classes, I don't really
mind.

Andras
_______________________________________________
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]