Firefox outerHTML, wo ist die Logik?

[Paul]

Hi,

nachdem ich mich nun seit Stunden plage, weil ich nicht drauf komme, dass ein Browser der innerHTML versteht nicht auch outerHTML begreift und ich somit andere Ursachen suchte, kann mir mal Jemand die Logik des Ganzen erklären, warum sich der Fuchs so verhalten soll?

Also "inner" ja, "outer" Nein.

Paul

[Paul]

Nachtrag:

Nun dachte ich das Problem(Löschen eines Elementes) durch remove.child oder ähnliches hinzubekommen, wenn ja leider outerHTML nicht geht.

Aber so einfach ist das ja auch nicht anzusprechen. Will ja keine Kindknoten sondern komplett.

Gibt es nicht eine einfache Möglichkeit einen kompletten Tag(Element) zu löschen?

Also sowas wie: document.getElementById('x').remove;

Normalerweise wärs einfach gewesen, bzw. ist einfach im IE:

document.getElementById('x').outerHTML='';

Paul

[ChrisB]

Hi,

Nun dachte ich das Problem(Löschen eines Elementes) durch remove.child oder ähnliches hinzubekommen, wenn ja leider outerHTML nicht geht.

Aber so einfach ist das ja auch nicht anzusprechen.

Natuerlich ist es.

Will ja keine Kindknoten sondern komplett.

Wenn du einen Konten entfernst, werden auch alles seine Nachfahrenknoten mit entfernt.

Gibt es nicht eine einfache Möglichkeit einen kompletten Tag(Element) zu löschen?

Ja, einen kompletten Knoten inklusive aller Nachfahren kann man aus dem DOM entfernen - eben mit removeChild.
Wo liegt dein Problem damit?

MfG ChrisB

[Paul]

Hallo Chris,

Gibt es nicht eine einfache Möglichkeit einen kompletten Tag(Element) zu löschen?

Ja, einen kompletten Knoten inklusive aller Nachfahren kann man aus dem DOM entfernen - eben mit removeChild.
Wo liegt dein Problem damit?

Das Problem dabei ist, das ich nicht immer genau weiss welchen Aufbau das DOM aktuell hat, da das ganze sehr dynamisch ist. Gut ich kann jetzt nachfragen was Parent ist und mich dann zum ersten Kind vorarbeiten, aber ist es auch das erste Kind oder doch nicht mehr. Also so richtig wohl fühle ich mich dabei nicht, sei es auch nur subjektiv. Oder siehst du das als absolut stabil an, also vergleichbar mit outerHTML, bzw habe ich einen Denkfehler?

Übrigens, deine Antwort zur Logik, schön und gut, auch wenn das ein MS Ding ist, wer A sagt sollte auch B sagen, dann hätten die sich auch innerHTML sparen sollen.

Am Rande:
Ich hatte in der Zwischenzeit andere lösungen probiert. So dachte ich mir ich nutze innerHTML und mit replace nehme ich den Start-und endtag wieder weg:

var teilbereich = document.getElementsByTagName('body')[0].innerHTML.replace(starttag,'');
var teilbereich = teilbereich.replace(endtag,'');
document.getElementsByTagName('body')[0].innerHTML = teilbereich;

Doch was muss ich da erleben, jetzt gehts im FF aber IE streikt, warum? weil der doch tatsächlich meinen Quelltext genauer die Tags rigoros gross schreibt, heute wundert mich nichts mehr. Das sind echt Tage da möchte man alles hinwerfen, wenn immer solche Kleinigkeiten sich zu einer ganzen Nachtarbeit hinziehen.

Gruss
Paul

[Daniel Richter]

Hallo,

Das Problem dabei ist, das ich nicht immer genau weiss welchen Aufbau das DOM aktuell hat

Wenn du das zu löschende Element gefunden hast (was dein Posting impliziert), kannst du das übergeordnete mit "parentNode" ermitteln.

Oder wo liegt dein Problem?

mfg. Daniel

[Paul]

Hi,

Wenn du das zu löschende Element gefunden hast (was dein Posting impliziert), kannst du das übergeordnete mit "parentNode" ermitteln.

klar kann ich das, nur müsste ich das Kind dann ja auch entsprechend identifizieren um es als zb. firstChild zu löschen. Aber wenn es das dritte, fuenfte, x-te ist, muss ich das wieder anders handlen, bzw explizit identifizieren.

Oder wo liegt dein Problem?

Das ich am liebsten einen ganz unproblematischen Ersatz für outerHTML  hätte, bei dem ich ein Element anhand ID identifiziere und dann lösche.

Aber scheinbar gibt es das Gewünschte so nicht.

Gruss
Paul

[Struppi]

Wenn du das zu löschende Element gefunden hast (was dein Posting impliziert), kannst du das übergeordnete mit "parentNode" ermitteln.

klar kann ich das, nur müsste ich das Kind dann ja auch entsprechend identifizieren um es als zb. firstChild zu löschen. Aber wenn es das dritte, fuenfte, x-te ist, muss ich das wieder anders handlen, bzw explizit identifizieren.

Wieso das?

Oder wo liegt dein Problem?

Das ich am liebsten einen ganz unproblematischen Ersatz für outerHTML  hätte, bei dem ich ein Element anhand ID identifiziere und dann lösche.

Dafür ist outerHTML die schlechteste Wahl.

Aber scheinbar gibt es das Gewünschte so nicht.

Natürlich! wie schon gesagt - solange du uns nicht zeigst, was du machst, können wir dir nicht konkret sagen, wie du es richtig machen könntest.

Struppi.

[Timo "God's Boss" Reitz]

Wenn du das zu löschende Element gefunden hast (was dein Posting impliziert), kannst du das übergeordnete mit "parentNode" ermitteln.
klar kann ich das, nur müsste ich das Kind dann ja auch entsprechend identifizieren um es als zb. firstChild zu löschen. Aber wenn es das dritte, fuenfte, x-te ist, muss ich das wieder anders handlen, bzw explizit identifizieren.

Häh? Du hast doch das Kind schon, dachte ich?

var node=[ref:self812;javascript/objekte/document.htm@title=document].[ref:self812;javascript/objekte/document.htm#get_element_by_id@title=getElementById('Hussa')];  
node.[ref:self812;javascript/objekte/node.htm#parent_node@title=parentNode].[ref:self812;javascript/objekte/node.htm#remove_child@title=removeChild(node)];

Löscht das Element mit der ID "Hussa" (alle Tests, die man eigentlich machen würde, noch außen vor gelassen).

[Paul]

Hi Timo,

Häh? Du hast doch das Kind schon, dachte ich?

na ja, das schon aber...

var node=[ref:self812;javascript/objekte/document.htm@title=document].[ref:self812;javascript/objekte/document.htm#get_element_by_id@title=getElementById('Hussa')];

node.[ref:self812;javascript/objekte/node.htm#parent_node@title=parentNode].[ref:self812;javascript/objekte/node.htm#remove_child@title=removeChild(node)];

  
... ich wusste nicht das man das so referenzieren kann "removeChild(knoten)"  
  

> Löscht das Element mit der ID "Hussa" (alle Tests, die man eigentlich machen würde, noch außen vor gelassen).  
  
Tests? Scheint herrvorragend zu klappen, könnte ein Probem dabei auftreteten?  
  
  
Vielen Dank, wäre in der Form nicht drauf gekommen, zumal die Beispiele bei Selfhtml bei mir den Eindruck erweckt hatten ich könnte keinen Knoten konkret ansprechen eher durch Schleifen oder erster und nächster.  
  
  
  
Noch eine andere, nebensächliche, Frage:  
  
Beim testen fiel mir auf, wenn ich den Quelltext mit javascript ausgebe, also zb. >> alert(document.getElementsByTagName('body')[0].innerHTML); << das der IE den Code enorm ändert. Gross/Kleinschreibung, In Tabellen wird <tbody> zugefügt, usw....  Gibts dafür eine plausible Begründung?  
  
  
Gruss und Dank  
Paul  
  
  

[Cheatah]

Hi,

Tests? Scheint herrvorragend zu klappen,

es ist kein Argument, dass etwas unter Laborbedingungen funktioniert.

könnte ein Probem dabei auftreteten?

DOM könnte dem Client unbekannt sein, das Element könnte keine parentNode besitzen.

Beim testen fiel mir auf, wenn ich den Quelltext mit javascript ausgebe, also zb. >> alert(document.getElementsByTagName('body')[0].innerHTML); << das der IE den Code enorm ändert.

Ja, tut er. Das ist seine interne Repräsentation des Objektes, die seine extrem starke Tendenz zu HTML anstatt XML verdeutlicht.

In Tabellen wird <tbody> zugefügt,

Nun, hier wäre es ein Fehler[1], wenn er dies nicht machen würde. Das <tbody>-Element ist in den meisten HTML-Derivaten Pflicht; häufig sind Start- und End-Tag optional und werden somit vollkommen korrekt hinzugefügt.

Cheatah

[1] Je nach Dokumenttyp.

[Timo "God's Boss" Reitz]

Hi Timo,

Häh? Du hast doch das Kind schon, dachte ich?
na ja, das schon aber...

var node=[ref:self812;javascript/objekte/document.htm@title=document].[ref:self812;javascript/objekte/document.htm#get_element_by_id@title=getElementById('Hussa')];

node.[ref:self812;javascript/objekte/node.htm#parent_node@title=parentNode].[ref:self812;javascript/objekte/node.htm#remove_child@title=removeChild(node)];

>   
> ... ich wusste nicht das man das so referenzieren kann "removeChild(knoten)"  

Wieso kann? Man muss! Es geht doch gar nicht anders, `removeChild`{:.language-javascript} erwartet immer einen Knoten.  
  

> > Löscht das Element mit der ID "Hussa" (alle Tests, die man eigentlich machen würde, noch außen vor gelassen).  
>   
> Tests? Scheint herrvorragend zu klappen, könnte ein Probem dabei auftreteten?  

Ja. Der Browser könnte `document`{:.language-javascript} nicht implementiert haben (unwahrscheinlich), ihm fehlen DOM-Eigenschaften/-Methoden (bei sehr alten Browsern) und natürlich könnte ein Element mit der gewünschten ID gar nicht existieren.  
  

> Vielen Dank, wäre in der Form nicht drauf gekommen, zumal die Beispiele bei Selfhtml bei mir den Eindruck erweckt hatten ich könnte keinen Knoten konkret ansprechen eher durch Schleifen oder erster und nächster.  

Aber es wird doch ein Knoten konkret angesprochen?  
  

> Noch eine andere, nebensächliche, Frage:  
>   
> Beim testen fiel mir auf, wenn ich den Quelltext mit javascript ausgebe, also zb. >> alert(document.getElementsByTagName('body')[0].innerHTML); << das der IE den Code enorm ändert. Gross/Kleinschreibung, In Tabellen wird <tbody> zugefügt, usw....  Gibts dafür eine plausible Begründung?  

Ja. In HTML (nicht XHTML) sind Element- und Attributnamen nicht case-sensitiv, Groß- und Kleinschreibung ist also egal. In [DOM (HTML) 1](http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html) ist schon die Rede davon, dass Großbuchstaben verwendet werden sollen, hat man dann wohl gleich so implementiert.  
Tabellen haben immer tbody-Elemente (bzw. eins), auch wenn diese nicht explizit in den Quelltext geschrieben wurden (oder per innerHTML). Das ist so festgelegt.  
Es gibt noch zig Weitere solcher Geschichten, deswegen ist der Code verändert. Im Prinzip sollte er aber die gleiche Bedeutung haben.

-- 
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.  
  
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:| 

[Daniel Richter]

Hallo,

... ich wusste nicht das man das so referenzieren kann "removeChild(knoten)"

removeChild() erwartet einen DOM-Node. Wie du ihn dir holst ist dieser Methode ziemlich egal.

Noch eine andere, nebensächliche, Frage:

Beim testen fiel mir auf, wenn ich den Quelltext mit javascript ausgebe, also zb. >> alert(document.getElementsByTagName('body')[0].innerHTML); << das der IE den Code enorm ändert. Gross/Kleinschreibung, In Tabellen wird <tbody> zugefügt, usw....  Gibts dafür eine plausible Begründung?

SGML ist zu komplex, als dass sämtliche Informationen in das DOM übertragen werden. Daher müssen einige Dinge nachträglich hinzugefügt werden (z.B. bei tbdoy), oder die Tag-Namen aufgrund der Case-Insensitivität in ein einheitliches Format gebracht werden.

Das ist übrigens auch einer der Gründe, weshalb ich X(HT)ML einfach schöner finde. Da wird alles so übersetzt wie es im Code steht und kann damit auch verlustfrei zurückkonvertiert werden (mal abgesehen von Leerzeichen zwischen Attributen und der Kurzschreibweise bei leeren Elementen).

mfg. Daniel

[Struppi]

Übrigens, deine Antwort zur Logik, schön und gut, auch wenn das ein MS Ding ist, wer A sagt sollte auch B sagen, dann hätten die sich auch innerHTML sparen sollen.

Da bin ich deiner Meinung, zumal innerHTML nicht unproblematisch ist und auch im IE nicht immer funktioniert. Schau dir mal ein paar von diesen suchergebnissen an. Aber innerHTML hat Vorteile, wenn es darum geht einfache HTML Strukturen schnell mal in ein Element einzufügen. Sobal es komplexer wird, sollte man die Finger davon lassen.

Gerade was du anscheinend versuchst - Knoten einfügen, löschen - geht wesentlich Komfortabler über die DOM Methoden. Um dir bei deinem Problem konkret zu helfen, müßte man allerdings Wissen, was du machst, am betsen mit einem Code Beispiel.

Struppi.

[Cybaer]

Hi,

Da bin ich deiner Meinung, zumal innerHTML nicht unproblematisch ist und auch im IE nicht immer funktioniert.

Ich teile die Meinung aller Browserentwickler (daß innerHTML sinnvoll ist), und wer ...

Schau dir mal ein paar von diesen suchergebnissen an.

... programmiert ohne die Doku zu lesen, ist eher *selbst* das Problem. =:-)

Gruß, Cybaer

[Struppi]

Hi,

Da bin ich deiner Meinung, zumal innerHTML nicht unproblematisch ist und auch im IE nicht immer funktioniert.

Ich teile die Meinung aller Browserentwickler (daß innerHTML sinnvoll ist), und wer ...

Ich glaube nicht, dass die Browserentwickler das gedacht haben, sie wurden eher von der Übermacht des IE überrollt und konnten gar nicht anders, weil auf jeder 2. Seite ein Skript mit innerHTML war. das zeigt ja schon, exemplarisch das die ersten Versionen des firefox soweit ich mich erinnere kein innerHTML konnten.

Schau dir mal ein paar von diesen suchergebnissen an.

... programmiert ohne die Doku zu lesen, ist eher *selbst* das Problem. =:-)

Ob alle Probleme darauf zurück zu führen sind ist eine andere Frage, aber das ist wie bei den Frames. Wer's kann für den ist es gut, für all anderen gibt viele Fallstricke

Struppi.

[Cybaer]

Hi,

Ich glaube nicht, dass die Browserentwickler das gedacht haben,

Zumindest sagen die Moz-Entwickler , daß sie innerHTML übernommen haben, weil es oft praktischer ist, als die einzelnen DOM-Methoden (und schneller). Jedenfalls habe ich das mal in einem Interview gelesen.

sie wurden eher von der Übermacht des IE überrollt und konnten gar nicht anders, weil auf jeder 2. Seite ein Skript mit innerHTML war.

Ob das damals schon so war, als innerHTML implementiert wurde, wage ich aber zu bezweifeln ...

... und wenn es nur um Kompatibilität ginge (was laut der Moz-Entwickler nicht das entscheidende Kriterium war - document.all kam ja auch erst viel später), dann hätte man ja auch gleich noch outerHTML und innerText implementiert.

Und: innerHTML wird standardisiert. outerHTML nicht.

Ob alle Probleme darauf zurück zu führen sind ist eine andere Frage, aber das ist wie bei den Frames. Wer's kann für den ist es gut, für all anderen gibt viele Fallstricke

Zur "gescheiten" Handhabung von Frames gibt es aber keine Doku, in der ein Anfänger lesen könnte. ;->

Gruß, Cybaer

[Struppi]

Ich glaube nicht, dass die Browserentwickler das gedacht haben,

Zumindest sagen die Moz-Entwickler , daß sie innerHTML übernommen haben, weil es oft praktischer ist, als die einzelnen DOM-Methoden (und schneller). Jedenfalls habe ich das mal in einem Interview gelesen.

Das sehe ich genauso, einen Benchmark gibt es auch auf Quirksmode und da ist innerHTML tasächlich schneller, was mich damals sehr überrascht hat.

sie wurden eher von der Übermacht des IE überrollt und konnten gar nicht anders, weil auf jeder 2. Seite ein Skript mit innerHTML war.

Ob das damals schon so war, als innerHTML implementiert wurde, wage ich aber zu bezweifeln ...

Du meinst beim Firefox implementiert? Da wage ich deinem Zweifel zu widersprechen. Zu der Zeit hatte der IE so eine Dominianz und andere Browser wurden von vielen Entwicklern mehr oder weniger ignoriert, dass hast du in allen Foren damals mitbekommen, zumal auch Opera schon früh innerHTML konnte, blieb den Mozilla Entwicklern gar nichts anderes übrig als auf diesen Zug aufzuspringen.

Und: innerHTML wird standardisiert. outerHTML nicht.

Ich habe nichts gegen innerHTML, nur muss man eben höllisch aufpassen, was man damit zusammenbauen will und je komplexer es wird umso besser beraten ist man, Elemente mit den DOM Methoden zu kreiren, zumal man in solchen Fällen ja i.d.R. auch Eventhandler und evtl. den Zugriff auf Elemente an anderer Stelle auch haben will. Deshalb ist innerHTML an vielen Stellen nützlich um in einem Skript mal etwas schnell anzuzeigen, um aber funktionalität einzubauen ist es zu vermeiden.

outerHTML läßt sich im FF übrigens relativ leicht nachbauen

Ob alle Probleme darauf zurück zu führen sind ist eine andere Frage, aber das ist wie bei den Frames. Wer's kann für den ist es gut, für all anderen gibt viele Fallstricke

Zur "gescheiten" Handhabung von Frames gibt es aber keine Doku, in der ein Anfänger lesen könnte. ;->

Die gibt es auch nicht für innerHTML, einmal wird nirgendwo deutlich auf die Fallstricke hingewiesen und zum zweiten ist die Doku von M$ nicht unbedingt Anfängerkompatibel.

Struppi.

[Cybaer]

Hi,

Zu der Zeit hatte der IE so eine Dominianz und andere Browser wurden von vielen Entwicklern mehr oder weniger ignoriert,

Keine Frage. Meine Bedenken gelten nur der Frage, ob damals bereits dermaßen viel mit DOM und/oder innerHTML programmiert wurde, daß das die entscheidende Relevanz gehabt hätte.

Und wie gesagt: document.all hat man erst später aus Kompatibilitätsgründen implementiert. Und das wurde damals sicherlich häufiger verwendet ...

dass hast du in allen Foren damals mitbekommen, zumal auch Opera schon früh innerHTML konnte, blieb den Mozilla Entwicklern gar nichts anderes übrig als auf diesen Zug aufzuspringen.

Opera unterstützt allerdings schon lange, anders als FF, das komplette IE-DOM - inkl. z.B. all und outerHTML. Davon abgesehen: Opera war, damals zumindest (eigentlich: bis V9), eine echte JS-Katastrophe, so buggy war die Implementation. Und außerdem: welchen Entwickler interessieren schon die paar Promille Opera-Nutzer?! >;->

Kaum einen - deswegen hat Opera ja das IE-DOM implementiert. :)

outerHTML läßt sich im FF übrigens relativ leicht nachbauen

Klar - ich mußte outerHTML sogar schon für den Opera nachbauen, obwohl er das eigentlich nativ unterstützt. Und: innerHTML läßt sich natürlich auch nachbauen. Allerdings ist natürlich native Unterstützung immer besser - schon aus Performanzgründen ...

Die gibt es auch nicht für innerHTML, einmal wird nirgendwo deutlich auf die Fallstricke hingewiesen

Also in der MS-Doku wird IMHO deutlich drauf hingewiesen.

und zum zweiten ist die Doku von M$ nicht unbedingt Anfängerkompatibel.

Schon weil sie wohl kaum ein Anfänger überhaupt kennt. >:->

Gruß, Cybaer

[Cybaer]

Nachtrag:

outerHTML läßt sich im FF übrigens relativ leicht nachbauen

Leider habe ich mir den Link erst nach dem Posten angeschaut: Also ja: Wenn man es unvollständig nachbaut, dann ist es natürlich wirklich *so* einfach.

Aber kompatibel zu outerHTML ist obig Funktion nicht. Die Attribute hat er komplett vergessen ...

... OK, das macht die Sache nicht viel komplizierter, umso unverständlicher, daß der Autor das nicht bedacht hat.

Gruß, Cybaer

[Timo "God's Boss" Reitz]

Das Problem dabei ist, das ich nicht immer genau weiss welchen Aufbau das DOM aktuell hat, da das ganze sehr dynamisch ist. Gut ich kann jetzt nachfragen was Parent ist und mich dann zum ersten Kind vorarbeiten, aber ist es auch das erste Kind oder doch nicht mehr. Also so richtig wohl fühle ich mich dabei nicht, sei es auch nur subjektiv. Oder siehst du das als absolut stabil an, also vergleichbar mit outerHTML, bzw habe ich einen Denkfehler?

outerHTML habe ich noch nie benutzt, ich wusste bisher gar nicht, dass es das gibt. Die DOM-Methoden sind, wenn man browserübergreifend und sauber arbeiten möchte, wesentlich verlässlicher. Ich verstehe nicht wirklich, wo dein Problem liegt, hast du die <http://de.selfhtml.org/javascript/objekte/node.htm@title=Dokumentation zu Knoten> auch wirklich gelesen und verstanden?

Übrigens, deine Antwort zur Logik, schön und gut, auch wenn das ein MS Ding ist, wer A sagt sollte auch B sagen, dann hätten die sich auch innerHTML sparen sollen.

Nein, warum? Ein Browserhersteller ist frei darin, was er implementiert. Er sollte sich darum bemühen, Standards zu implementieren, aber bei proprietären Erweiterungen anderer Hersteller sollte er genau schauen, was sinnvoll ist und was nicht. outerHTML habe ich z.B. noch nie benutzt und auch innerHTML kann man in der Regel vermeiden (strikt gesprochen natürlich immer).

Am Rande:
Ich hatte in der Zwischenzeit andere lösungen probiert. So dachte ich mir ich nutze innerHTML und mit replace nehme ich den Start-und endtag wieder weg:

Ohne Beispiel würde das hier nach beispielloser Frickelei klingen. ;-)

[Cybaer]

Hi,

Die DOM-Methoden sind, wenn man browserübergreifend und sauber arbeiten möchte, wesentlich verlässlicher.

Wenn der IE nicht wäre. :) Wenn man browserübergreifend verläßlich arbeiten möchte, dann bedeutet das: outerHTML beim IE, DOM bei allen anderen.

Gruß, Cybaer

[Timo "God's Boss" Reitz]

Wenn der IE nicht wäre. :) Wenn man browserübergreifend verläßlich arbeiten möchte, dann bedeutet das: outerHTML beim IE, DOM bei allen anderen.

Und doppelten Code schreiben? Oder einen komplizierten, ineffizienten Wrapper? DOM beim IE funktioniert eigentlich ganz gut (soll heißen: ausreichend, um es zu benutzen).

[Cybaer]

Hi,

Und doppelten Code schreiben?

Ja, so ist es ggf.

DOM beim IE funktioniert eigentlich ganz gut (soll heißen: ausreichend, um es zu benutzen).

Absolut - und für 99,99% der Fälle ausreichend. Es gibt aber eben leider auch Fälle, wo dem nicht so ist.

Gruß, Cybaer

[ChrisB]

Hi,

nachdem ich mich nun seit Stunden plage, weil ich nicht drauf komme, dass ein Browser der innerHTML versteht nicht auch outerHTML begreift und ich somit andere Ursachen suchte,

http://community.de.selfhtml.org/zitatesammlung/zitat231

kann mir mal Jemand die Logik des Ganzen erklären, warum sich der Fuchs so verhalten soll?

Also "inner" ja, "outer" Nein.

Beides war kein Standard, sondern wurde von MicroSoft erfunden.
innerHTML haben andere Browser inzwischen uebernommen, aber bei outerHTML hat man sich bei den Mozilla-Entwicklern wohl gedacht, dass das ein zu selten gebrauchtes Konstrukt ist, als dass es eine Implementierung wert waere.

MfG ChrisB