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

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: Using KDOM in Quanta
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-06-07 1:56:42
Message-ID: 200506070856.42713.jens () kdewebdev ! org
[Download RAW message or body]


> > Structure tree.
>
> I don't know if it would be bad. It would give a stronger indication to the
> user to what he should fix. 

I know, this is very bad :-) 
If you have a error at the very beginning of the document the tree will be 
almost empty and useless. So I have to fix the errors top down to get a 
usefull tree? What a horror! Think about a document someone else created, I 
have to suffer because the other author did it wrong and I have to fix 
his/her error to get the structure tree? 
I hate it if a tool force me to work in a specific way and try to educate me 
to do it right. Where right means what the deleloper of the tool mean is 
right and not what I, as a user, think is right. 
To make it very clear here. This would be a radical change in Quanta's 
philosophy and if Quanta would choose to go this way I most likely will think 
about another tool that fits more to what I think is the right approach. I do 
not want to threat here if Quanta wants to go this way I am fine with it.

> We should also ask ourselves what use is given 
> for the structure tree.
> BTW, do you think it's importante for the node tree to show non XML nodes?
> I can't see no use for that.

I do see a use, but it is more theory than practical experience. You should 
ask people who are working a lot with PHP to get a better picture. 

> > And VPL should also display a broken page.
>
> It already does, because it's rendered by KHTML.

So are we talking about the future or about what we have now? We came to the 
point where we agreed about having only _one_ tree is the way to go. Where is 
KHTML then? 


> > > > The parsing of special areas is already separated from the HTML/XML.
> > >
> > > But it's all going to the same tree and it's done in a more or less
> > > syncronized way IIUC.
> >
> > Yes and what is wrong with this?
>
> It would be interesting and a lot easier if we completely separate the
> parsing of special areas from the parsing of HTML, don't you think? I would
> like to know if special area nodes need to belong with the XML node tree.
> My idea is to reuse some XML parser (and make it tolerable to errors if
> possible) and have the script functionality as a different module.

For me it is only partly about how intersting or easy stuff is. The more 
important question is what the users expect and want. And I do not see that 
we should careless drop features we have because it is easier or more 
interesting. Quanta must go a step foreward not backwards. 

Of course the internal coding is independent and here it is about what is 
easier or more interesting. So I agree that reusing an existing parser can be 
a good choice and it is also smart to untie XML and script parsing. But 
detecting the script areas when you are parsing XML is also smart because it 
prevents another parsing just for area detection.


> > What do you mean by syncronized? You could
> > read in Andras mail that the special areas are skipped first and parsed
> > later.
>
> I was not very accurate but they are mixed in Parser::parse(). There is a
> first pass for detecting special areas along with the XML stuff.

Yes and how do you see a way to change this without loosing information about 
the special areas?


> P.S.: IRC? ;)

Better not yet, this is very important and should be available for others.

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