heise.de: erste Details zum IE7

[wahsaga]

hi,

heise berichtet: Details über Internet Explorer 7 enthüllt

allzu spektakuläres enthält der artikel zwar nicht, aber zumindest in punkto png-unterstützung wollen die redmonder sich wohl mal langsam der konkurrenz annähern.

dass dinge wie tabbed browsing oder integrierter RSS-reader für viele nutzer immer interessanter werden, scheinen sie wohl auch gecheckt zu haben.

nur ein klitzekleiner wermutstropfen aus "unserer" sicht als webseiten-ersteller:

Allerdings soll der IE 7 offenbar immer noch nicht vollständig den sechs Jahre alten Web-Standard CSS 2 unterstützen.

na toll, dann wird's wohl trotzdem immer noch bei vielen "für den IE optimierten" seiten bleiben ...

gruß,
wahsaga

[Cheatah]

Hi,

heise berichtet: Details über Internet Explorer 7 enthüllt

danke für die Info.

nur ein klitzekleiner wermutstropfen aus "unserer" sicht als webseiten-ersteller:

Nein, nicht nur einer. Aus Textschnipseln wie "So sollen die Voreinstellungen restriktiver sein" und "Internet Explorer 7 wird unter Windows XP mit Service Pack 2 laufen" entnehme ich die starke Vermutung, dass der IE 7 auf dem IE 6 Code basieren wird. Ich sehe es jedoch als eines der Hauptprobleme _aller_ aktuellen IE-Versionen an, dass ihre History bis hinunter zum Mosaic-Code geht; nie wurde mal ein Browser völlig neu entwickelt. Hysterisch gewachsen. Das Ergebnis kann sich, je länger dies vorangetrieben wird, von Schrott nicht signifikant unterscheiden.

na toll, dann wird's wohl trotzdem immer noch bei vielen "für den IE optimierten" seiten bleiben ...

Vermutlich werden wir zusätzlich mit alten und neuen CSS-Bugs zu kämpfen haben, während diverse der CSS-Hacks nicht mehr greifen.

Cheatah

[wahsaga]

hi,

Aus Textschnipseln wie "So sollen die Voreinstellungen restriktiver sein" und "Internet Explorer 7 wird unter Windows XP mit Service Pack 2 laufen" entnehme ich die starke Vermutung, dass der IE 7 auf dem IE 6 Code basieren wird.

würde ich daraus nicht unbedingt(!) schließen wollen.

wieso sollte ein neu geschriebener IE nicht auch zu XP SP2 "kompatibel" sein?

Ich sehe es jedoch als eines der Hauptprobleme _aller_ aktuellen IE-Versionen an, dass ihre History bis hinunter zum Mosaic-Code geht; nie wurde mal ein Browser völlig neu entwickelt. Hysterisch gewachsen. Das Ergebnis kann sich, je länger dies vorangetrieben wird, von Schrott nicht signifikant unterscheiden.

ack.
und _wenn_ sie es denn so machen - dann wird sich vermutlich auch nicht viel verbessern.

Vermutlich werden wir zusätzlich mit alten und neuen CSS-Bugs zu kämpfen haben, während diverse der CSS-Hacks nicht mehr greifen.

nun ja, das ist einer der gründe, warum ich von CSS-hacks sowieso weitestmöglichen abstand halte.

gruß,
wahsaga

[Cheatah]

Hi,

würde ich daraus nicht unbedingt(!) schließen wollen.

ich auch nicht - weder unbedingt, noch wollen ;-)

wieso sollte ein neu geschriebener IE nicht auch zu XP SP2 "kompatibel" sein?

Es geht nicht um das "auch", sondern um das (quasi) "nur". Augenscheinlich sind Systemabhängigkeiten gegeben, die eine neu geschriebene Software nicht haben müsste.

und _wenn_ sie es denn so machen - dann wird sich vermutlich auch nicht viel verbessern.

Ja :-(

Vermutlich werden wir zusätzlich mit alten und neuen CSS-Bugs zu kämpfen haben, während diverse der CSS-Hacks nicht mehr greifen.
nun ja, das ist einer der gründe, warum ich von CSS-hacks sowieso weitestmöglichen abstand halte.

Klar. Die Entscheidung ist letzten Endes halt, wo man den IE mit schlechterer Darstellung bedienen will, bzw. wo dies in die Kategorie "fatal" fallen würde.

Cheatah

[Abbi]

Geht man nach http://www.microsoft-watch.com/article2/0,1995,1776290,00.asp wird es eine PNG-Alpha-Unterstützung geben. Das wäre doch mal endlich die Erlösung!

Grüße
Abbi

[wahsaga]

hi,

Geht man nach http://www.microsoft-watch.com/article2/0,1995,1776290,00.asp wird es eine PNG-Alpha-Unterstützung geben.

ja, sagte der heise-artikel doch auch schon ...

gruß,
wahsaga

[molily]

Hallo,

zumindest in punkto png-unterstützung wollen die redmonder sich wohl mal langsam der konkurrenz annähern.

Das wird kein Kunststück sein, der Code dazu existiert ja schon in MSIE 5.5, Stichwort AlphaImageLoader.

Mathias

[Alexander]

Hi,

zumindest in punkto png-unterstützung wollen die redmonder sich wohl mal langsam der konkurrenz annähern.

Das wird kein Kunststück sein, der Code dazu existiert ja schon in MSIE 5.5, Stichwort AlphaImageLoader.

Was leider nur den Verdacht stärkt, dass es kein "neuer" Browser wird, sondern dass nur etwas makeup in Form von tabbed-browsing auf den angestaubten IE 6 kommt.

Dass IDN-Unterstüzung eingebaut wird ist eher ein "muss" als ein "kann", sofern der IE nicht in ein paar Jahren ganz von der Bildfläche verschwunden sein soll.

Viele Grüße...

Alex :)

[LeKuchen]

Hallo,

kommt aber spät, war schon heute Mittag auf heise gemeldet...;o)

Das Problem sehe ich darin:
Der Verlust an Marktanteilen zwingt Microsoft entgegen der Planung eine neue Version des IE frühzeitig auf den Markt zubringen.
Extremer Zeitdruck bedeutet aber leider eine unausgereifte Software...

Ich hätte imho eine echte, durchdachte "Neu"entwickung und Auslieferung zusammen mit Longhorn besser gefunden, als eine Erweiterung des IE6 um ein paar Features Mitte des Jahres.

Gruß,
LeKuchen

[Orlando]

Hallo LeKuchen,

Der Verlust an Marktanteilen zwingt Microsoft entgegen der Planung eine neue Version des IE frühzeitig auf den Markt zubringen.

ein paar Jahre halte ich für ein recht langes Intervall. Aber es wäre ja nicht das erste Mal, dass MS eine Entwicklung verschlafen hätte und dann mit aller Macht versucht, verlorene Marktanteile zurückzugewinnen. Das ist in der Vergangenheit immer wieder gelungen.

Extremer Zeitdruck bedeutet aber leider eine unausgereifte Software...

Also für mich ist der IE schon lange „reif“. ;-) Ich bin schon gespannt, welche Auswirkungen der IE7 auf ActiveX und ähnliche Spielereien haben wird.

Ich hätte imho eine echte, durchdachte "Neu"entwickung und Auslieferung zusammen mit Longhorn besser gefunden, als eine Erweiterung des IE6 um ein paar Features Mitte des Jahres.

Bis dahin könnte diese Schlacht bereits verloren sein. Die Opera-Freunde besetzen bereits den „Highend“-Bereich und die Gecko-Jünger sind bei der breiten Masse fleißig am Missionieren. Ich warte ja nur noch auf den Tag, an dem zwei altmodisch angezogene Leute vor der Tür stehen und mir den „Surfturm“ andrehen wollen. *fg*

Grüße
Roland

[Alexander]

Hi,

heise berichtet: Details über Internet Explorer 7 enthüllt

heise berichtet auch über die Dritte Beta-Version von Opera 8 mit SVG-Grafiken, was meines Erachtens viiiiel interessanter als ein IE 7 ist ;o)

Viele Grüße...

Alex :)

[Ashura]

Hallo Alexander.

Warum wechselt hier nahezu jeder den Themenbereich zu "CGI"?

Gruß, Ashura

[Alexander]

Hi,

Warum wechselt hier nahezu jeder den Themenbereich zu "CGI"?

wahsaga hat in seinem Ausgangsposting als Thema CGI ausgewählt (warum auch immer - vermutlich verklickt), mir ist dies nicht aufgefallen und deshalb habe ich es bei meinem Posting auch nicht geändert.

Viele Grüße...

Alex :)

[Ashura]

Hallo Alexander.

wahsaga hat in seinem Ausgangsposting als Thema CGI ausgewählt

Ups. Das ist mir wiederum nicht aufgefallen...

(warum auch immer - vermutlich verklickt),

Oder aber er meint, dass der IE nicht in den Themenbereich "Browser" passen würde... ;)

Gruß, Ashura

[wahsaga]

hi,

wahsaga hat in seinem Ausgangsposting als Thema CGI ausgewählt (warum auch immer - vermutlich verklickt)

stimmt :-)

gruß,
wahsaga

[derletztekick]

Hallo,

heise berichtet auch über die Dritte Beta-Version von Opera 8 mit SVG-Grafiken, was meines Erachtens viiiiel interessanter als ein IE 7 ist ;o)

Nicht wirklich, da er scheinbar wieder schlechter wird als besser *arg*
Sowohl die beta2 als auch nun die 3er können nicht mit:

var db=window.frames["lejs_input"].document.body.innerHTML;

auf eine TXT(!) Datei zugreifen, die in einem iFrame leigt... Die 7er Version und die beta 1 (wie mir jemand im Forum verraten hatte seinerzeit) kommt damit problemlos klar. Somit ist es für mich uninteressant, was er an neuen Feauters bekommt, wenn er nicht mal die "einfachen" Sachen aus seiner Vorgängerversion kann...

Mit freundlichem Gruß
Micha

[Ashura]

Hallo derletztekick.

Somit ist es für mich uninteressant, was er an neuen Feauters bekommt, wenn er nicht mal die "einfachen" Sachen aus seiner Vorgängerversion kann...

Warum hilfst du dann nicht, Opera zu verbessern?

Ich würde es selbst machen, wenn ich dein Problem nachvollziehen könnte.

Gruß, Ashura

[derletztekick]

Hallo,

Warum hilfst du dann nicht, Opera zu verbessern?

Ich habe bereits nach der Beta 2 einen Report geschrieben, und? Verbessert haben sie ihn ja nicht.

Ich würde es selbst machen, wenn ich dein Problem nachvollziehen könnte.

Dann sollte Dir das helfen:
http://home.media-n.de/13881/lejs_db_kreisklasse_west_ee_0405.html

Mit freundlichem Gruß
Micha

[Ashura]

Hallo derletztekick.

Ich habe bereits nach der Beta 2 einen Report geschrieben, und? Verbessert haben sie ihn ja nicht.

Das liegt im Ermessen der Entwickler.
Ich hoffe, dass sie Bugs ihrer Priorität entsprechend ausbessern.

Dann sollte Dir das helfen:
http://home.media-n.de/13881/lejs_db_kreisklasse_west_ee_0405.html

Hm... Sieht für mich wie eine clientseitige include-Funktion aus.

Gruß, Ashura

[derletztekick]

Hallo Ashura,

http://home.media-n.de/13881/lejs_db_kreisklasse_west_ee_0405.html

Hm... Sieht für mich wie eine clientseitige include-Funktion aus.

Ist es auch. Das IFrame ist nur Mittel-Zum-Zweck, um eine Schnittstelle zum einlesen zu haben. Funktioniert ja auch in FF, NS, Mozilla, IE und Opera 7.xx
Nur die neuen beta Versionen von Opera 8 können damit ncihts anfangen. Ich nehm auch gern was anderes, um das IFrame anzusprechen bzw. auszulesen als

var db=window.frames["lejs_input"].document.body.innerHTML;

Mit freundlichem Gruß
Micha

[Ashura]

Hallo derletztekick.

Ich nehm auch gern was anderes, um das IFrame anzusprechen bzw. auszulesen als

var db=window.frames["lejs_input"].document.body.innerHTML;

Ich für meinen Teil würde dies mit SSI oder PHP machen.
Gibt es bei deiner clientseitigen Methode irgendwelche Vorteile, oder begründet sie sich nur darauf, dass keine serverseitigen Methoden erforderlich sind?

Gruß, Ashura

[derletztekick]

Hallo,

Ich für meinen Teil würde dies mit SSI oder PHP machen.
Gibt es bei deiner clientseitigen Methode irgendwelche Vorteile, oder begründet sie sich nur darauf, dass keine serverseitigen Methoden erforderlich sind?

Sie begründet sich daraus(?), da es eine reine clientseitige Lösung - also ein JavaScript - sein soll und somit zB auf Hobbyseiten eingesetzt werden kann, die keine serverseitigen Sprachen zur Verfügung haben. Eine 1zu1 Kopie des Scriptes gibts auch als PHP Version (zumindest auf meinm Rechner).

Für den Funktionsumfang sind sicher keine serverseitigen Methoden notwendig - sofern JS aktiviert ist. Ob ich 1+1 mit JavaScript rechne oder mit PHP oder was auch immer ist sicher irrelevant, wobei die JS Lösung hier um einiges schneller ist als bspw. PHP.

Der Ausgangspunkt ist also, es soll eine reine JS Lösung bleiben und sie soll einfach zu bedienen sein. Darum will ich ja eine CSV (ähnliche) Datei. Theoretisch könnte man ja auch ein externes *.js machen, in dem das Feld bereits steht, welches durch den Einlesevorgang sonst erst entsteht.

Aber Felder sind nun mal nicht jedermanns Sache und ohne ein wenig Grundwissen manchmal auch schwer zu verstehen. Eine Datei, die wie eine CSV aufgebaut ist, kann ein einfacher Texteditor bis hin zu EXCEL...

Mit freundlichem Gruß
Micha

[Ashura]

Hallo derletztekick.

Danke für die Erläuterung. :)

Gruß, Ashura

[derletztekick]

Hallo Ashura,

Danke für die Erläuterung. :)

hmm, keine Ursache *habichwasfalschesgesagt*

Mit freundlichem Gruß
Micha

[Ashura]

Hallo derletztekick.

Danke für die Erläuterung. :)
hmm, keine Ursache *habichwasfalschesgesagt*

Nein, wieso? Ich weiß nun, dass es so etwas gibt, es sei dahin gestellt, wie verlässlich.
Sollte einmal jemand so etwas benötigen, gibt es also eine Möglichkeit.

Ich bleibe bei meinen include(); Funktionen. ;)

Gruß, Ashura

[derletztekick]

Hallo,

Nein, wieso?

Es kam so, wie soll ich sagen? abrupt...
Naja, habe ich dann vll falsch interpretiert.

Mit freundlichem Gruß
Micha

[Cheatah]

Hi,

Sowohl die beta2 als auch nun die 3er können nicht mit:
var db=window.frames["lejs_input"].document.body.innerHTML;
auf eine TXT(!) Datei zugreifen, die in einem iFrame leigt...

warum sollte man auch ein document.body-Objekt in einem Dokument finden, welches über kein <body>-Element verfügt?

Die 7er Version und die beta 1 (wie mir jemand im Forum verraten hatte seinerzeit) kommt damit problemlos klar.

Schön, dass dieser Mangel nun behoben wurde.

Cheatah

[derletztekick]

Hallo,

Schön, dass dieser Mangel nun behoben wurde.

*lol* benenn ich die txt nach HTML um gehts komischer weise auch mit Opera (der IE kann es dann nicht, lass mich raten "Schön, dass dieser Mangel nun behoben wurde" im IE)...

Es wäre mir lieber gewesen, wenn Du mir einen Lösungsvorschlag gegeben hättest...

Mit freundlichem Gruß
Micha

[Cheatah]

Hi,

Schön, dass dieser Mangel nun behoben wurde.
*lol* benenn ich die txt nach HTML um

handelt es sich dann auch um eine HTML-Ressource, bzw. liegt die Datei im lokalen Filesystem?

gehts komischer weise auch mit Opera

Die Start-Tags <html> und <body> sind bei hinreichend unstriktem HTML optional, ebenso wie ihre End-Tags. Das <body>-Element ist also auch dann vorhanden, wenn nichts davon im Code steht.

(der IE kann es dann nicht, lass mich raten "Schön, dass dieser Mangel nun behoben wurde" im IE)...

Nein. Wenn es sich um eine HTML-Ressource handelt, zeigt dieses Beispiel nur, wie dämlich der IE ist.

Es wäre mir lieber gewesen, wenn Du mir einen Lösungsvorschlag gegeben hättest...

Lösungsvorschlag wofür? Opera weist ein Fehlverhalten nicht mehr auf. Das ist _kein_ Problem, welches es zu lösen gälte.

Cheatah

[derletztekick]

Hallo,

handelt es sich dann auch um eine HTML-Ressource, bzw. liegt die Datei im lokalen Filesystem?

Nein, es ist und bleibt eine CSV Datei, der ich eine andere Endung gebe. Dabei macht es einen Unterschied, ob sie txt oder html heißt (sowohl für den IE als auch für Opera)

Die Dateien liegen auf einem Server: http://home.media-n.de/13881/lejs_db_kreisklasse_west_ee_0405.html

Nein. Wenn es sich um eine HTML-Ressource handelt, zeigt dieses Beispiel nur, wie dämlich der IE ist.

Wie gesagt, ist eine CSV Datei ohne HTML-Tags, sondern mit Tabellarisch angeordneten Werten, die durch ein Trennzeichen ";" getrennt sind.

Lösungsvorschlag wofür? Opera weist ein Fehlverhalten nicht mehr auf. Das ist _kein_ Problem, welches es zu lösen gälte.

Stimmt, man muss sich nicht bemühen, auch noch ein kleines Stück weiter zudenken.

Mit freundlichem Gruß
Micha

[MudGuard]

Hi,

handelt es sich dann auch um eine HTML-Ressource, bzw. liegt die Datei im lokalen Filesystem?
Nein, es ist und bleibt eine CSV Datei, der ich eine andere Endung gebe. Dabei macht es einen Unterschied, ob sie txt oder html heißt (sowohl für den IE als auch für Opera)

Im HTTP-Umfeld geht es nicht um Dateien, sondern um Ressourcen.
Und welcher Art eine Ressource ist, wird in diesem Umfeld am content-type festgemacht.

Und dieser Content-Type wird von den Webservern (falls keine anderen Angaben dazu vorliegen) an der Endung der auf dem Server liegenden Datei festgemacht, wenn die Webserver aus den Dateien Ressourcen machen.

cu,
Andreas

[derletztekick]

Hallo Andreas,

Im HTTP-Umfeld geht es nicht um Dateien, sondern um Ressourcen.
Und welcher Art eine Ressource ist, wird in diesem Umfeld am content-type festgemacht.

Und dieser Content-Type wird von den Webservern (falls keine anderen Angaben dazu vorliegen) an der Endung der auf dem Server liegenden Datei festgemacht, wenn die Webserver aus den Dateien Ressourcen machen.

Ähm, ja, hmm... Wenn ich dich richtig verstanden habe, dann ist die Benennung mit *.txt ja die richtige, was ich dort letztlich wie drin stehen habe, ist dabei ja irrelevant oder nicht?

Also ob dort "Hallo SelfHTML" oder "TeamA;TeamB;" steht macht das txt-File ja nicht "ungültig" - es enthält Text. Versteh nicht so ganz, worauf Du hinauswillst?

Mit freundlichem Gruß
Micha

[Cheatah]

Hi,

Ähm, ja, hmm... Wenn ich dich richtig verstanden habe, dann ist die Benennung mit *.txt ja die richtige, was ich dort letztlich wie drin stehen habe, ist dabei ja irrelevant oder nicht?

der Inhalt ist irrelevant, genau. Der Dateiname _eigentlich_ auch - er wird nur _meistens_ vom Server als Indiz verwendet, welchen Content-Type er ausliefern soll. Für einen HTTP-Client ist dieser dann das _einzige_[1] Kriterium, um was für einen Datentyp es sich handelt.

Also ob dort "Hallo SelfHTML" oder "TeamA;TeamB;" steht macht das txt-File ja nicht "ungültig" - es enthält Text. Versteh nicht so ganz, worauf Du hinauswillst?

Darauf, dass die Umbenennung der Datei dafür sorgen _kann_, dass es sich um eine HTML-Ressource handelt.

Cheatah

[1] Außer er fehlt, oder der Client stammt aus dem Hause Microsoft. Aber das wundert sicher nicht :-)

[derletztekick]

Hallo Cheatah,

der Inhalt ist irrelevant, genau. Der Dateiname _eigentlich_ auch - er wird nur _meistens_ vom Server als Indiz verwendet, welchen Content-Type er ausliefern soll.

Damit würde er ja, wenn ich es TXT nenne, genau das richtige machen.

»»Für einen HTTP-Client ist dieser dann das _einzige_[1] Kriterium, um was für einen Datentyp es sich handelt.
Auch das wäre dann egal, da es sich ja um eine TXT Datei handelt. Nur der Aufbau dieser, macht sie erst zu einer CSV. Wobei es doch trotzdem eine txt bleibt...

Darauf, dass die Umbenennung der Datei dafür sorgen _kann_, dass es sich um eine HTML-Ressource handelt.

Die Umbenennung will ich ja auch nicht unbedingt, es sollte nur zeigen, das Opera8, nur weil es meine TXT nicht einließt, die selbe Datei aber mit der Endung(!) htm jedoch schon, es trotzdem kein deut besser macht - wie Du vorher noch beschrieben hattest.

»»Außer er fehlt, oder der Client stammt aus dem Hause Microsoft.
Um eine Textdatei zu "erkennen"?, daran sollte er nicht scheiter - egal aus welchem Hause er stammt. Die Geckos können es ja auch (sowohl mit der einen als auch mit der anderen Endung).

Bevor wir uns weiter irgendwie im Kreis drehen ;-) Es scheint Dich ja zu stören, das ich fälschlicher weise(?) body.innerHTML nutze - dem ist doch so?

Gibt es den eine andere Möglichkeit, auf den Inhalt einer Datei zu zugreifen mit JavaScript, die in einem IFrame liegt und die Endung *.txt hat? Das ist doch der springende Punkt meiner (vll unberechtigten) Kritik an Opera.

Mit freundlichem Gruß
Micha

[Henryk Plötz]

Moin,

Damit würde er ja, wenn ich es TXT nenne, genau das richtige machen.

Ja. Nur musst du halt auch beachten, dass Text-Dateien, die keine HTML-Dateien sind, keine HTML-Elemente enthalten, insbesondere auch kein body-Element.

Die Umbenennung will ich ja auch nicht unbedingt, es sollte nur zeigen, das Opera8, nur weil es meine TXT nicht einließt,

Opera liest die Datei richtig ein, du greifst nur nicht richtig drauf zu.

Gibt es den eine andere Möglichkeit, auf den Inhalt einer Datei zu zugreifen mit JavaScript, die in einem IFrame liegt und die Endung *.txt hat? Das ist doch der springende Punkt meiner (vll unberechtigten) Kritik an Opera.

Nicht auf das body-Element zugreifen, da es ja keins gibt?!?

[derletztekick]

Hallo Henryk,

Opera liest die Datei richtig ein, du greifst nur nicht richtig drauf zu.

Ja, sie stellt sie sicher im IFrame dar, aber sie wird nicht in meine Variable (db) 'eingelsen'. Das heißt, Opera interpretiert meinen Versuch nicht so, wie ich es gern sehen würde... ;-)

Gibt es den eine andere Möglichkeit, auf den Inhalt einer Datei zu zugreifen mit JavaScript
Nicht auf das body-Element zugreifen, da es ja keins gibt?!?

Mal angenommen (ich habs natürlich auch getestet) ich schreibe in meine Datei <body>, dann ändert das an der Sache auch nichts.

Das ich nicht auf das Body Element zugreifen soll, habe ich glaube ich nun auch verstanden, nur wie dann?

var db = window.frames["lejs_input"].document.innerHTML;
bzw.
var db = lejs_input.document.innerHTML; geht ja mit Sicherheit nicht.

Da es kein HTML gibt in diesem Frame, macht ja eigentlich auch innerHTML irgendwie wenig Sinn, oder? Wie schimpft sich den mein Element, auf das ich zugreifen soll bzw. allg. gefragt, was müsste statt dessen für:
document.body.innerHTML hin?

Mit freundlichem Gruß
Micha

[molily]

Hallo,

Das ich nicht auf das Body Element zugreifen soll, habe ich glaube ich nun auch verstanden, nur wie dann?

Wurde doch schon gesagt bzw. du bist selbst darauf gekommen:
1. Du nimmst ein HTML-Dokument. Das muss nicht notwendigerweise HTML-Markup enthalten, das ergänzen die Browser, solange der MIME-Typ text/html ist.
2. Du nimmst eine XML-Datei und bringst die Daten z.B. in Elementen anstatt kommasepariert unter. Oder du bringst deine kommageteilten Daten in einem Wurzelelement unter, z.B. <?xml version="1.0" encoding="iso-8859-1" ?><daten>a;b;c</daten>. Das Ganze wird als application/xml oder text/xml ausgeliefert.
3. Du nutzt XMLHttpRequest für neuere Operas, womit du Textdateien, HTML-Dateien oder XML-Dateien in einen String einlesen kannst. Am sinnvollsten ist eine Kombination mit Iframes wie bei http://www.howtocreate.co.uk/tutorials/jsexamples/importingXML.html.

Da es kein HTML gibt in diesem Frame, macht ja eigentlich auch innerHTML irgendwie wenig Sinn, oder? Wie schimpft sich den mein Element, auf das ich zugreifen soll bzw. allg. gefragt, was müsste statt dessen für:
document.body.innerHTML hin?

Es geht so in neueren Operas nicht. document hat keine Eigenschaften oder Methoden, mit denen du auf den Textdatei-Inhalt zugreifen könntest. Ich sehe auch keinen Sinn darin, ein voriges Verhalten plötzlich zu deaktivieren. Allerdings sollte das kein Problem für dich darstellen, siehe die obigen Möglichkeiten.

Mathias

[derletztekick]

Hallo Molily,

Danke, es hilft mir aber nur bedingt. Alle Deine drei Lösungen funktionieren nicht im IE. XML ja so oder so nicht, wie auch auf Deiner verlinkten Seite in der Übersichtstabelle zu sehen ist. Und die Umbenennung der Datei nach HTML, was ich durchaus als akzeptabel halte ließt mir der IE fehlerhaft ein.

Lasse ich mir die Variable db mit einem ALERT zeigen, ist sie optisch vollständig. Nichtsdestotrotz wird nur die erste Zeile ausgewertet. Heißt also, der IE kann mein

var rows = db.split("\n");

nicht mehr korrekt umsetzen, die Zweite Split'tung

var columns = rows[i].split(";");

wiederum macht er korrekt.

Wie sieht der Zeilenumbruch denn nach der Umbenennung (auf einmal) aus? ISt der Umbruch dadurch verloren gegangen?

Mit freundlichem Gruß
Micha

[molily]

Hallo,

Alle Deine drei Lösungen funktionieren nicht im IE. XML ja so oder so nicht, wie auch auf Deiner verlinkten Seite in der Übersichtstabelle zu sehen ist.

Sowohl XML DOM als auch XMLHttpRequest funktionieren im MSIE/Windows, wie dort angegeben ist.

Lasse ich mir die Variable db mit einem ALERT zeigen, ist sie optisch vollständig. Nichtsdestotrotz wird nur die erste Zeile ausgewertet. Heißt also, der IE kann mein
var rows = db.split("\n");
nicht mehr korrekt umsetzen

Ja, tatsächlich.

Wie sieht der Zeilenumbruch denn nach der Umbenennung (auf einmal) aus? ISt der Umbruch dadurch verloren gegangen?

Der Zeilenumbruch wird vom MSIE zu einem Leerzeichen umgewandelt. Hast du einmal mit <pre>...</pre> und innerText experimentiert?

Mathias

[derletztekick]

Hallo Mathias,

Sowohl XML DOM als auch XMLHttpRequest funktionieren im MSIE/Windows, wie dort angegeben ist.

ich habe nur kurz in die Tabelle geguckt und mir das Bsp angesehen und dabei festgestellt, das es im IE nicht funktioniert. Daraufhin habe ich das geschrieben... Jetzt wo Du es erwähnt hast, habe ich es dann auch gefunden.

Der Zeilenumbruch wird vom MSIE zu einem Leerzeichen umgewandelt. Hast du einmal mit <pre>...</pre> und innerText experimentiert?

Ein Leerzeichen? hmm, das ist ja denkbar schlecht, da ein Verein ja im Namen ein solches beinhalten könnte SV Musterteam oder so.
Mit pre habe ich nciht gearbeitet, wüsste momentan auch nicht, wie ich es in meinem Zusammenhang nutzen könnte. Das einzige was mir dazu momentan einfällt ist, das die Geckos bei meiner bisherigen Methode (einlesen als TXT-File) ein <pre> </pre> um meinen Datensatz gesetzt haben. Daraufhin habe ich dann eine kleine Schleife geschrieben, die mit HTML Code wieder aus meinen Datensatz zieht. Wo müsste ich mein Experiment mit <pre> ansetzen?

InnerTEXT hatte ich auch zunächst natürlich Probiert, bzw gedacht, das dies der sinnhaftere Befehl statt innerHTML für mein Vorhaben sei. Versucht hatte ich es - nach Deinem Hinweis so gar noch einmal - mit:
var db = document.getElementById("lejs_input").innerText
FireFox zeigt mir jedoch im alert(db) an, das db nicht definiert ist.
Muss ich es anders nutzen?

Mit freundlichem Gruß
Micha

[molily]

Hallo,

Mit pre habe ich nciht gearbeitet, wüsste momentan auch nicht, wie ich es in meinem Zusammenhang nutzen könnte.

Ich meinte das als Lösung des MSIE-Problems, wenn du mit einer HTML-Datei arbeiten solltest. <pre>Daten</pre> in die HTML-Datei schreiben und über das DOM darauf zugreifen. innerHTML liefert dann den String mit unangetasteten Zeilenumbrüchen.

InnerTEXT hatte ich auch zunächst natürlich Probiert, bzw gedacht, das dies der sinnhaftere Befehl statt innerHTML für mein Vorhaben sei.

Ich dachte, bei innerText nimmt MSIE die Umwandlung Zeilenumbruch zu Leerzeichen nicht vor, das war aber ein Irrtum.

FireFox zeigt mir jedoch im alert(db) an, das db nicht definiert ist.

Firefox kennt kein innerText. innerHTML reicht ihm sowieso, würdest du eine HTML-Datei verwenden, ebenso wie bei Textdateien.

Ich verstehe nicht, wieso du zu keiner Lösung kommst. Alle Vorgehensweisen wurden geschildert. Wenn lediglich Opera 8 das Problem ist, dann kann das Script Textdateien nutzen und XMLHttpRequest, wenn document.body nicht existiert. Und es gibt dutzende andere Möglichkeiten.

Mathias

[derletztekick]

Hallo Mathias,

Dann werd ich wohl ein wenig mehr Hilfe benötigen...

Wenn lediglich Opera 8 das Problem ist, dann kann das Script Textdateien nutzen und XMLHttpRequest

Mein english ist leider nicht so begandet, das ich mch erstmal nach einer deutschen Version umgesehen habe.
http://molily.de/dom-load-and-save Deine Seite oder zufall?
und
http://www.formatvorlage.de/mozine/archives/000134.html

habe ich gefunden und schienen auf den ersten Blick ganz hilfreich.
Da ich sowas noch nie gemacht habe, stebt mein Wissen daher auch gegen Null^^

Also, am "einfachsten" sah ja das hier aus:
var request = new XMLHttpRequest();
request.onload = handler;
request.open("GET", "meine.txt");
request.send(null);

Über responseText soll es dann möglich sein, auf den Inhalt der Datie zu zugreifen... Soweit das Bsp.

Setz ich es ein, bekomme ich einen Scriptfehler "handler" ist unbekannt. Leider steht auf der Seite nicht, was dafür in Frage kommt.

Wäre der Ansatz so richtig oder bin ich da schon auf den falschen Weg? wenn es richitg ist, was erwartet "request.onload"?

Mein zweiter Versuch war dann:
var parser = new DOMParser();
var doc = parser.parseFromString("meine.txt","text/html");
alert (doc);

Bekomme ich auch eine Fehlermeldung, ändere ich den Content-Type testweise in text/xml, dann liefert mir FF zumindest ein Objekt XMLDocument zurück. Opera hingegen so oder so eine Fehlermeldung.

Mein dritter Versuch ;-) War dann folgender:
var parser = document.implementation.createLSParser(null);
try {
var doc = parser.parseURI('meine.txt');
} catch (e) {
window.alert('parser.parseURI: Fehlercode ' + e.code);
}
Auch hier bekomme ich eine Fehlermeldung, das "parser" undefiniert ist. Ich habe ihn null gesetzt, da ich bei der W3C folgendes gefunden hatte: "In order to create a LSParser for any kind of schema types (i.e. the LSParser will be free to use any schema found), use the value null." wenn ich das richtig übersetzt habe, dann soll ich den wert auf null setzten, für jeden x-beliebigen (Daten)Typ...

Bin Dir doch sehr verbunden, wenn Du mir noch eine weiter Hilfestellung gibst.

Mit freundlichem Gruß
Micha

[ziegenmelker]

Hallo derletztekick,

ich will dich ja jetzt nicht auf völlig andere Überlegungen bringen, aber ist es nicht denkbar, daß du die cvs-Dateien notfalls manuell(Kommandozeile) von einem PHP oder Perl-Script parsen lässt, das alle Werte in Javascrip-Variablen umsetzt? Du wärst zumindest nicht von serverseitiger PHP-Unterstützung abhängig.

cu,
ziegenmelker

[derletztekick]

Hallo ziegenmelker,

ich will dich ja jetzt nicht auf völlig andere Überlegungen bringen,

*hehe* Ich seh eh nicht so recht durch, was ich da gerade mache...

aber ist es nicht denkbar, daß du die cvs-Dateien notfalls manuell(Kommandozeile) von einem PHP oder Perl-Script parsen lässt, das alle Werte in Javascrip-Variablen umsetzt? Du wärst zumindest nicht von serverseitiger PHP-Unterstützung abhängig.

Sondern? Wo/wie soll der User es parsen lassen, wenn er kein PHP hat?

Zu dem anderen mit XMLHttpRequest:
Das hier muss ja schon irgendwie richtig sein, da ich keine Fehlermeldungen mehr erhalte - leider auch kein String^^

var request = new XMLHttpRequest();
request.open("GET", "meine.txt", true);
request.send(null);

alert(request.responseText);
liefert mir einen leeren String zurück.

alert(request.readyState);
liefert mir 1 zurück. Wenn das 4 wäre, dann müsste er den String haben - vermute ich mal.

0 # UNINITIALIZED, das Objekt wurde erzeugt, aber keine Verbindung mit open() geöffnet.
1 # LOADING, Verbindung geöffnet, aber noch keine Anfrage gesendet.
2 # LOADED, Status ist verfügbar, das Dokument noch nicht.
3 # INTERACTIVE, Teile des Dokuments sind in responseText und responseXML verfügbar.
4 # COMPLETED, das Dokument ist fertig geladen und geparsed.

Die Frage ist, wie erreiche ich Staus 4???

Mit freundlichem Gruß
Micha

[ziegenmelker]

Hallo Micha,

Sondern? Wo/wie soll der User es parsen lassen, wenn er kein PHP hat?

ich hatte vermutet, daß _du_ die Spielergebnisse als cvs-Datei bekommst und auf den Server stellst, der unter Umständen keine Script-Unterstützung bietet. Wenn ich mich da geirrt habe, sorry.

Zu dem anderen mit XMLHttpRequest:

Da kann ich dir leider noch nicht weiterhelfen, habe ich noch nichts mit gemacht. Es klingt jedoch so interessant, daß ich mich damit sehr bald einmal beschäftigen werde.

cu,
ziegenmelker (auch Micha :-))

[derletztekick]

Hallo Micha^^,

ich hatte vermutet, daß _du_ die Spielergebnisse als cvs-Datei bekommst und auf den Server stellst, der unter Umständen keine Script-Unterstützung bietet.

Nee, jede kleine Seite, die kein PHP oder ähnliches hat, aber eine "konfortable" Lösung sucht, eine Liga zu verwalten, möchte ich damit ansprechen. Es ersparrt ja doch ne Menge arbeit. Stell Dir vor, Du musst nach jedem Spieltag alle Spielpläne, die Spieltage und die Tabelle von zwei Ligen oder so aktualisieren, so musst Du nur eine Datei machen und gut. Konqueror 3.4 geht übrigens auch, so dass ich zumindest ein breites Spektrum ausnutze - was mit PHP sicher um einiges größer wäre aber wie gesagt, es richtet sich vorranging an Leute ohne PHP.

eine PHP Version ist ja als 1zu1 kopie auch in Arbeit:
http://www.derletztekick.com/leagueeditor/

Das ist aber "nur Spielerei", da ich mich mit PHP nicht so gut auskenne (mit JS ja eigentlich auch nichtm, wie ich bei diesem Thema gemerkt habe^^) und mal testen wollte, in wie weit ich es schaffe, ein Script umzuschreiben. Letztlich bin ich damit zufrieden, dass es sowiet scheinbar funktioniert hat. Zweiter "Vorteil", das Script greift auf die selbe Datenstruktur zu, wie die JS Variante. Somit ist ggf ein Umstieg auch später noch möglich, sofern man zB ein Archiv angelegt hat, wenn man zB den Server gewechselt hat und PHP auf einmal zur Verfügung steht.

Zu dem anderen mit XMLHttpRequest:

Da kann ich dir leider noch nicht weiterhelfen, habe ich noch nichts mit gemacht. Es klingt jedoch so interessant, daß ich mich damit sehr bald einmal beschäftigen werde.

Ich habe es auch noch nie gehört - bis Mathias so nett war, mich daruf zu bringen - Danke an dieser Stelle noch mal. Zunächst dachte ich ja schon, das ich auf verlorenen Posten stehe mit meinem Problem, da alle nur geschrieben habe, wa ich falsch mache, bzw. was die Browser in dem Fall falsch machen, aber keiner einen Lösungsansatz geben konnte. XMLHttpRequest ist echt ne schöne Sache und man kann sicher, wenn man so richtig durchsieht^^ auch viel mit machen. Die Geckos können es auch, sie haben nur Probleme mit den deutschen Umlauten - ich vermute, weil ich keinen Zeichensatz in der CSV angebe - sicher bin ich mir da aber nicht.

Mit freundlichem Gruß
Micha

[molily]

Hallo,

http://molily.de/dom-load-and-save. Deine Seite oder zufall?

Das ist schon meine Seite, dort geht es allerdings um DOM Load and Save, eine XMLHttpRequest ähnliche Technik, die dich hier aber nicht weiter kümmern sollte. Mit DOM Load and Save lassen sich nämlich keine Textdateien einlesen, nur XML-Dateien.

Also, am "einfachsten" sah ja das hier aus:
var request = new XMLHttpRequest();
request.onload = handler;
request.open("GET", "meine.txt");
request.send(null);

handler ist der Name einer Funktion, die ausgeführt wird, wenn die Anfrage fertig geladen ist. In dieser Funktion kannst du dann auf responseText zugreifen.
function handler () {
  alert(request.responseText);
}

Alternativ kannst du den Event-Handler onreadystatechange verwenden (das ist wohl die empfohlene Vorgehensweise). Dieser wird immer gefeuert, wenn sich der readyState ändert. Wenn der readyState 4 ist, kannst du auf responseText zugreifen.
request.onreadystatechange = handler;
function handler () {
  if (request.readyState == 4) {
    alert(request.responseText);
    /* ... */
  }
}

Mein dritter Versuch ;-) War dann folgender:
var parser = document.implementation.createLSParser(null);

DOM Load and Save ist eine ganz andere Geschichte, die um einiges komplizierter ist als XMLHttpRequest.
Daher nur zur Vollständigkeit: createLSParser() erwartet als ersten Parameter den Modus (»The mode argument is either MODE_SYNCHRONOUS or MODE_ASYNCHRONOUS«), das heißt wie in meinem Beispiel document.implementation.MODE_SYNCHRONOUS.

Ich habe ihn null gesetzt, da ich bei der W3C folgendes gefunden hatte: "In order to create a LSParser for any kind of schema types (i.e. the LSParser will be free to use any schema found), use the value null." wenn ich das richtig übersetzt habe, dann soll ich den wert auf null setzten, für jeden x-beliebigen (Daten)Typ...

Das bezieht sich auf den zweiten Parameter createLSParser().

Mathias

[derletztekick]

Hallo,

Danke für die Erklärung!!

Alternativ kannst du den Event-Handler onreadystatechange verwenden (das ist wohl die empfohlene Vorgehensweise). Dieser wird immer gefeuert, wenn sich der readyState ändert. Wenn der readyState 4 ist, kannst du auf responseText zugreifen.
request.onreadystatechange = handler;
function handler () {
  if (request.readyState == 4) {
    alert(request.responseText);
    /* ... */
  }
}

Wäre das eine bessere Lösung, als mit (false)
request.open("GET", lejs_db_url, false);
"d.h. der JavaScript-Interpreter wartet mit der Ausführung, bis das Dokument geladen wurde, ansonsten funktioniert das Laden asynchron."

Mit freundlichem Gruß
Micha

[derletztekick]

Hallo,

so habe ich es jetzt:

var request = new XMLHttpRequest();
request.open("GET", "meine.txt", false);
request.send(null);

alert(request.responseText);

und das Scheint zu funktionieren? Das alert liefert zumindest meinen String zurück ;-)) Und der Inhalt kann an die Variable db weitergegeben werden, von wo aus sie dann auch in Opera korrekt verarbeitet werden kann/wird.

Nun muss ich es nur noch schaffen, irgendwie die Operaversionen zu trennen, da zB die 7.54 das wiederum nicht kann (dafür aber den weg mit dem iFrame). Kann ich neben window.opera auch eine Versionsabfrage machen, die zuverlässig ist?

Mit freundlichem Gruß
Micha

[molily]

Hallo,

Nun muss ich es nur noch schaffen, irgendwie die Operaversionen zu trennen, da zB die 7.54 das wiederum nicht kann (dafür aber den weg mit dem iFrame). Kann ich neben window.opera auch eine Versionsabfrage machen, die zuverlässig ist?

Browser-  bzw. Versionsabfragen brauchst du nicht. Du fragst ab, ob du auf document.body im iframe zugreifen kannst. Wenn nicht (document.body ist in Opera 8 »null«), dann prüfst du, ob das Objekt XMLHttpRequest existiert.

if (window.frames["lejs_input"].document && window.frames["lejs_input"].document && window.frames["lejs_input"].document.body && typeof(window.frames["lejs_input"].document.body.innerHTML) != "undefined") {
  /* extrahiere über innerHTML */
} else if (XMLHttpRequest) {
  /* extrahiere über XMLHttpRequest */
}

Mathias

[derletztekick]

Hallo Mathias,

if (window.frames["lejs_input"].document && window.frames["lejs_input"].document && window.frames["lejs_input"].document.body && typeof(window.frames["lejs_input"].document.body.innerHTML) != "undefined") {
  /* extrahiere über innerHTML */
} else if (XMLHttpRequest) {
  /* extrahiere über XMLHttpRequest */
}

Wow, soviel kann man nun ausschließen ;-) Auf die Idee, nach
if (XMLHttpRequest) zu fragen bin ich nach kurzer Überlegung dann auch gekommen, da die Geckos die Umlaute in der TXT nicht entziffern können (Schade), habe ich noch ein document.all hinzugefügt, damit diese es auch über das Frame laden...

---
if((window.XMLHttpRequest)&&(document.all)){
var request = new XMLHttpRequest();
request.open("GET", lejs_db_url, false);
request.send(null);
var db = trim(replaceHtml(request.responseText));
}
else {
var db=trim(replaceHtml(window.frames["lejs_input"].document.body.innerHTML));
}
db += '\n';
....

---

Würde das nicht schon reichen? Es schließt natürlich keine Browser aus, die werder das eine noch das andere können, aber soviele werden wohl bspw. mit Netscape 4 nicht meher unterwegs sein, oder?

Mal noch was anderes, ich würde auch gern mein iFrame im Script verbauen, offline hat das bisher auch funktioniert aber online funktioniert es nur bei einer schnellen Verbindung zB DSL. Ist die Verbindung langsamer (so wie meine = max 200kbits/s), muss man die Seite erst neu laden, um die Tabellen zu sehen. Er "schaffte" es also nicht, das Frame so schnell zu laden/erstellen, wie es nötig wäre. Somit beginnt der "lese" Vorgang bereits zu früh, was unweigerlich dazu führt, das nichts (oder ein Fehler) ausgegeben wird. Mit setTimeout() habe ich auch versucht, die Funktion readfile(); zu verzögern, aber nachdem die Zahl bereits 1000 überschritt, habe ich es wieder rückgängig gemacht und das Frame im Quelltext normal deklariert. Hast Du hier vll auch noch ne Idee für mich?

Mit freundlichem Gruß
Micha

[molily]

Hallo,

if((window.XMLHttpRequest)&&(document.all)){

Browserabfragen über unbeteiligte Objekte sind meistens Käse. Frage einfach ab, ob die Objekte zur Verfügung stehen, die du verwenden willst. M.M.n. in der von mir beschriebenen Reihenfolge, es sei denn, du willst Konqueror auch mit XMLHttpRequest versorgen, denn der zeigt einen Download-Dialog für die Textdatei an und kennt document.all.

Würde das nicht schon reichen? Es schließt natürlich keine Browser aus, die werder das eine noch das andere können, aber soviele werden wohl bspw. mit Netscape 4 nicht meher unterwegs sein, oder?

Darüber würde ich gar nicht spekulieren, sondern einfach prüfen, ob document.body und document.body.innerHTML zur Verfügung steht, damit geht man für ältere und zukünftige Browser auf Nummer sicher.

Er "schaffte" es also nicht, das Frame so schnell zu laden/erstellen, wie es nötig wäre. Somit beginnt der "lese" Vorgang bereits zu früh

Beim iframe-Element sollte ein load-Event passieren, wenn der Inhalt fertig geladen wurde. Erst dann solltest du mit dem Lesevorgang beginnen: <iframe ... onload="lese()"></iframe>. Alternativ den onload des ganzen Dokuments nutzen, was aber eine sichtbare Verzögerung zur Folge hätte.

Mathias

[derletztekick]

Hallo Mathias,

Browserabfragen über unbeteiligte Objekte sind meistens Käse.

hmm, stimmt natürlich und klingt doch sehr überzeugend ;-)

Habe es nun so gemacht:
if (window.frames["lejs_input"].document.body && window.frames["lejs_input"].document && (typeof(window.frames["lejs_input"].document.body.innerHTML)) != "undefined") {
var db=trim(replaceHtml(window.frames["lejs_input"].document.body.innerHTML));
   }

else if (window.XMLHttpRequest){
var request = new XMLHttpRequest();
request.open("GET", lejs_db_url, false);
request.send(null);
var db = trim(replaceHtml(request.responseText));
}

else {
return false;
}

Somit sollte ja, wenn keiner der ersten beiden Bedingungen zutrifft, nichts mehr passieren - also die Funktion abgebrochen werden, oder?
http://home.media-n.de/13881/lejs_db_kreisliga_vorpommern_0203.html

Beim iframe-Element sollte ein load-Event passieren, wenn der Inhalt fertig geladen wurde. Erst dann solltest du mit dem Lesevorgang beginnen: <iframe ... onload="lese()"></iframe>. Alternativ den onload des ganzen Dokuments nutzen, was aber eine sichtbare Verzögerung zur Folge hätte.

Das mache ich bereits, zwar noch einen Tick später mit window.onload=startlejs; aber nachdem selben Prinzip.

Ich möchte aber das IFrame _im_ JavaScript verbauen, also mit createElement zB. Das hat offline auch ganz gut funktioniert - finde leider die Version nciht mehr. Als ich es aber hochgeladen habe, ging es ohne refresh nicht - das Frame war also zum Zeitpunkt des lesevorgangs noch nicht (vollständig) geladen. Auch die If-Abfrage, ob das Frame da ist, hat nichts genutzt :-(

Weisst wie ich meine?

Mit freundlichem Gruß
Micha

[molily]

Für einen HTTP-Client ist dieser [Content-Type] dann das _einzige_[1] Kriterium, um was für einen Datentyp es sich handelt.
[1] Außer er fehlt, oder der Client stammt aus dem Hause Microsoft. Aber das wundert sicher nicht :-)

Microsoft-Bashing will gekonnt sein. Auch Opera und Gecko missachten den Content-Type in manchen Fällen, etwa wenn schrottig konfigurierte Webserver bekannte Binärformat-Dateien als text/plain senden.

[Tim Tepaße]

Hallo wahsaga,

Details über Internet Explorer 7 enthüllt

Nun ja. Wirklich über Neues informieren tut Heise da aber nicht. Zumindest nicht, was nicht schon vorher irgendwo bekannt war. Schließlich gibt es inzwischen sogar ein Weblog der IE Entwickler (Achtung: Marketing Speak).

Allerdings soll der IE 7 offenbar immer noch nicht vollständig den sechs Jahre alten Web-Standard CSS 2 unterstützen.

Wenn ich dieses Posting im obigen Blog so lese, dann ist das noch nicht so raus, eher, daß der IE im Quirks Mode wie bisher funktionieren soll, im Strict Mode soll der Support evtl. ausgebaut werden. Aber genaueres sagen sie natürlich nicht.

Tim