[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: Paulo Moura Guedes <moura () kdewebdev ! org>
Date: 2005-06-07 2:25:10
Message-ID: 200506070325.10622.moura () kdewebdev ! org
[Download RAW message or body]
On Tuesday 07 June 2005 02:56, Jens Herden wrote:
> > > 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.
Ok. My idea was that an empty structure tree would not prevent you from
editing the document, but I guess you are right as the tree might be
important for some users.
> > 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.
This is an important issue as it could determine if special areas must belong
with the rest of the tree.
> > > 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?
I don't understand the question. Are you suggesting we should change our
rendering engine?
> > > > > 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.
I'm not talking about features but an approach on how to implement things.
> Of course the internal coding is independent and here it is about what is
> easier or more interesting.
Yes.
> 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.
But you don't parse the script areas in detail twice so I doubt it would turn
out to be a performance bottleneck. We could also have a lazy approach for
parsing XML. IMHO this performance issues are premature and we should focus
on choosing the right way of doing things.
> > > 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?
The idea was to separate the waters as discussed above, but I'm not sure if I
understood correctly.
> > P.S.: IRC? ;)
>
> Better not yet, this is very important and should be available for others.
I though that we might accelerate our ideas and then could expose them to the
list.
--
Paulo Moura Guedes
http://caixamagica.org
http://kdewebdev.org
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic