'Re: Open Issues'

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

List:       kde-kafka
Subject:    Re: Open Issues
From:       Emmanuel Touzery <manu () minds ! cs ! may ! ie>
Date:       2000-10-27 13:39:20
[Download RAW message or body]

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() )???

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