'Re: Open Issues'

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

List:       kde-kafka
Subject:    Re: Open Issues
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2000-10-27 15:15:43
[Download RAW message or body]

On Friday 27 October 2000 13:39, Emmanuel Touzery wrote:
> On Thu, 26 Oct 2000, Thomas Zander wrote:
> > Something we could then do is to add code to the tokenizer to accept
> > "plugin-tokens". In normal html viewing there would be no plugins
> > registered, in kafka however tokens like "whitespace", "php-tag" etc,
> > could be added. Which would be then be stored in the dom-tree.
> > Example:
> >
> > <html>
> >   <?echo $text; ?>
> > </html>
> >
> > in normal khtml this would create
> >  [html]
> >      [texttag] <?echo $bgcolor; ?>"
> >
> > But after registering the php and whitespace objects we would have
> >   [html]
> >      [kafka-whitespace]  "   "
> >      [kafka-php tag] "echo $bgcolor;"
> >      [whitespace] "\n"
> >
> > Implementation specific, all kafka objects would have to subclass a
> > "unknown-token" in the khtml lib, some smart code would have to sneak
> > into the tokenizer to parse the "plugin" tokens.
>
> But kafka is not going to use this text anyway. I mean, unknown tags, php
> scripts etc. We are not going to tamper with them.
> So what is the interest in writing complicated code to handle them and
> knowing precisely their nature (IF it is possible) while we _won't_ use
> this information???
> Storing them as Strings is much simpler and as powerful no????
>
> So my question will be : what do you win if you do this plugin interface
> against just treating them as strings (and providing an additional
> function in KHTML or Kafka, say DOM::PowerLoad() instead of
> DOM::load() )???

I agree that there isn't much point in adjusting the DOM to take these extra 
tags if we are not going to specifically do something with them. the question 
we need to ask is "what are we going to do with these extra tags that are in 
the DOM". Where I can see this new tokenizer being useful is in saving hidden 
details such as coordinates in the DOM. A second benifit is for new tags that 
are developed either commercially or at the W3C. We could add them easily 
with a parser that looks for unknown tags to KHTML. The problem lies when the 
KHTML developers want to support the tags that we support; there will be lots 
of checking who has done what and changing codebase.

What we need to agree on before we discuss the tokenizer or upgrading the 
KHTML parser is what extra information the DOM does not support. an example 
of this is hidden data we may wish to store that makes the WYSIWYG editing 
possible. We need to discuss this WYSWIYG editing layer and how it interacts 
with KHTML to understand if it affects the dOM in a way that the DOM does'nt 
support.

I think the best thing we can do is to organize a meeting in #kafka on IRC to 
discuss these items interactively. Could everyone make?

I was gonna suggest the time of 7pm GMT next wednesday. Is that OK for 
everyone?

	Jono

-- 
Jono Bacon - jono@kde.org
KDE/Qt Developer - Founder of Linux UK
_______________________________________________
Kde-kafka mailing list
Kde-kafka@master.kde.org
http://master.kde.org/mailman/listinfo/kde-kafka

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