[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:       Frans Englich <frans.englich () telia ! com>
Date:       2005-06-07 11:09:55
Message-ID: 200506071109.55239.frans.englich () telia ! com
[Download RAW message or body]


First of all, it should be noted that I'm no expert in Quanta & related; I'm 
just adding a comment here and there -- food for thought & "interesting 
input", nothing else.

On Monday 06 June 2005 14:34, Paulo Moura Guedes wrote:
> On Monday 06 June 2005 15:16, Jens Herden wrote:
> > I agree totally here. But the idea of Quanta is different. Quanta does
> > not restrict the user in doing wrong things. It only support the user in
> > doing it right. You can write what you want but should get the best
> > possible support to be standard conform.
> > The consequence is that our parser can not be very strict and must even
> > work when the document is totally broken. But we offer support for HTML
> > tidy and maybe we can give more support in the future.
> >
> > Another point, Quanta does not only pares HTML/XML it also parses PHP and
> > here we come to an area where no XML parser is working anymore.
>
> What if the parsing of special areas were completely separated from
> HTML/XML? Then we could have a strict HTML/XML parser. One could continue
> to edit in source mode, as it doesn't depend on the HTML/XML tree and in
> VPL we could find a way to signalize the error, as Frans proposed; we
> depend on KHTML anyway so we wouldn't loose anything...

The quirk mode parser I was referring to in my previous mail(replied by Jens) 
was KHTML's parser -- it has rigorous testing for doing quirk mode, etc. I 
don't know how modularized its design is for re-usability, but with the 
khtml2 porting it has likely improved, and it can likely be changed 
considering it's KDE 4(but I don't know anything about it).

On the topic of parsing PHP and so forth; one way is to let the builder(if you 
use KHTML, you could inherit from KHTMLDocumentBuilder such that your builder 
can play nice with KHTML), and let it build specialize processing 
instructions, "QuantaPHPProcessingInstructionImpl", for PIs with name "php", 
and register each such node in a list in the "QuantaDocumentImpl". In this 
way you can quickly loop over all php instructions(without having to walk the 
tree), and access the PHP code as strings, which you can invoke a PHP parser 
on(and attach any data structures created from the PHP parsing on the 
QuantaPHPProcessingInstructionImpl, perhaps).

This is a difficult and confusing topic!


Cheers,

		Frans

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