'Talk with Lars Knoll'

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

List:       kde-kafka
Subject:    Talk with Lars Knoll
From:       Stefan Schimanski <1Stein () gmx ! de>
Date:       2000-10-24 17:04:10
[Download RAW message or body]

<schimmi> zum aktuellen stand:
<schimmi> es existiert momentan ne implementation des editors, der direkt die 
dom manipuliert
<lars> ja
<schimmi> zum erzeugen des html codes wird im prinzip die dom direkt 
ausgegeben
<schimmi> dabei gehen natuerlich alle information verloren, die von khtml 
nicht in der dom gespeichert werden
<schimmi> also kommentare, zeilumbrueche, unbekannte tags, etc.
<lars> kommentare lassen sich evtl aendern. Zeilenumbrueche und unbekannte 
tags sind ein problem.
<schimmi> ich hatte die idee, dass man eine ebene einfuehrt, die im prinzip 
mehr oder weniger direkt die ausgabe vom tokenizer speichert
<schimmi> also ne lineare liste von tags, textzeilen, kommentaren etc
<schimmi> jedes solches element dieser liste bekommt einen zeiger auf das 
entsprechende dom element
<lars> hmmm... das sollte moeglich sein, wenn wir den parser etwas 
modifizieren, so das ihr davon ableiten koennt.
<schimmi> daran dachte ich
<lars> im Prinzip muessen wir nur eine Funktion im parser virtuell machen.
<lars> das einzige Problem das ich im Augenblick sehe ist, dass wir ziemlich 
viele Sachen in die public API mit reinnehmen muessten, die ich lieber privat 
halten wuerde.
<schimmi> vielleicht koennte man teile des editors nach kdelibs verlagern
<schimmi> das zu loesene problem ist vor allem, dass wir herausfinden 
muessen, wie wir aus aenderungen im tokenbuffer aenderungen in der dom 
herleiten koennen
<schimmi> wenn also der tag der tabelle geaendert wird, sollten die 
aenderungen auf die dom uebertragen werden
<lars> das ist nicht ganz so einfach...
<schimmi> das ist mir bewusst
<lars> keine Ahnung wie man dass am besten loest.
<schimmi> aber die aktuelle loesung, dass die DOM nodes geaendert werden, ist 
auch nicht viel besser
<schimmi> die dom elemente haben doch bestimmt nicht alle ne "schreibene" 
api, um anderungen zu machen
<lars> sorry?
<lars> Du kannst im Prinzip das ganze dokument ueber DOM calls aufbauen.
<schimmi> momentan hantiert der editor mit den dom objekten
<lars> mit den dom objekten kannst Du im Prinzip alles machen, was man 
braucht.
<schimmi> gibt es eigentlich immer ne 1:1 relation zwischen tags und DOM 
objekten?
<lars> Es gibt ein paar erweiterungen zur DOM, die fuer kafka drin sind.
<lars> ja
<lars> jein
<lars> ein DOM objekt ist ein HTML element. Das heisst, <body> zusammen mit 
</body> ist ein Element in der DOM
<schimmi> dann sollte das mit dem tokenbuffer doch eigentlich funktionieren
<schimmi> der tokenizer erstellt diesen buffer und der parser macht daraus 
seinen dom tree
<lars> hmmm... ich seh den vorteil noch nicht richtig.
<schimmi> irgendwo muessen wir die informationen speichern, die nicht in der 
dom sind
<schimmi> oder wir erweitern die dom so, dass das wir die extradatenstruktur 
nicht brauchen
<schimmi> s/das //
<lars> waere die andere Moeglichkeit. Ist wahrscheilich eleganter.
<lars> Das problem ist, dass wir dann trotzdem sichergehen muessen, dass das 
rendering dieselben ergebnisse liefert.
<schimmi> da kommt nur wieder die frage auf, wie man daraus schnell den html 
code erzeugt
<lars> gute frage.
<lars> aber wie erzeugst Du andersrum aus der toeknlist schnell den DOM baum
<lars> s/erzeugst/aenderst/
<schimmi> eigentlich sollte es doch kein problem sein, eine zweite version 
der html datei im speicher zu halten, die die problematischen informationen 
enthaelt
<schimmi> es gibt doch eigentlich nur die beiden faelle:
<schimmi> 1) man aendert was im html code direkt und die aenderungen sollen 
sofort in khtml erscheinen
<schimmi> in dem fall kann man das entfernen, hinzufuegen ud aendern von 
attributen einfach auf die dom uebertragen
<schimmi> ich denke, das bekommt man hin
<schimmi> 2) man ist im wysiwyg modus und aendern ein dom element
<lars> was, wenn jemand neue elemente einfuegt. Es ist oft nicht ganz einfach 
aus der tokenliste zu ersehen, wo das element im DOM baum landen wird.
<schimmi> in dem fall such man sich das entsprechende element im tokenbuffer 
und akutalisiert die attribute
<schimmi> du meinst, wenn er html elemente hinzufuegt?
<schimmi> auf jeden fall weiss man, dass noch kein dom element dafuer 
existiert
<lars> na sowas wie: <table><tr><td>... => <table><tbody><tr><td>
<lars> da muss der ganze DOM baum umorganisiert werden.
<lars> brb
<lars> zurueck, muss aber gleich wieder gehen...
<schimmi> in so einem fall wie oben hast du aber auch ohne meinen tokenbuffer 
probleme
<lars> was mir auf jeden fall wichtig ist, ist dass wir das ganze so 
hinbekommen, das wir moeglichst wenig von khtmls internals oeffentlich machen 
muessen
<schimmi> man muesste herausfinden, bis zu welchem dom node man alles neu 
erstellen muss
<lars> stimmt. reparsen ist da wahrscheinlich am einfachsten.
<lars> alles innerhalb von der table
<lars> ich werd den parser so aufbohren, dass node.innerHTML(some html) 
funktioniert.
<lars> also ware das ein call in der dom: table.innerHTML( "<tbody><tr>..." );
<schimmi> das waere natuerlich schon cool
<schimmi> der erstellt dann alle children neu?
<lars> ja
<lars> brauchen wir eh fuer javascript.

-- 
#! /bin/sh
for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done | \
   perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' | gunzip
_______________________________________________
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] 