nicht angemeldet
Einlesen mit XMLHttpRequest() begrenzen
Hallo,
ich habe ersmal eine verständnis Frage, warum wird diese XML Datei nicht als solche im Browser angezeigt, sondern als TXT Datei angezeigt?
http://home.media-n.de/13881/keywords.xml
Wenn ich sie offline von meiner Festplatte lade, funktionierts...
Mein 2tes Problem. Ich habe, nachdem mit Mathias für meinen kleinen Ligamanager das Einlesen von Dateien mittels XMLHttpRequest() näher gezeigt hatte, mal versucht eine kleine JavaScript Suchmaschine zu schreiben.
Dabei lege ich in einem Array fest, welche Seiten durchsucht werden sollen, die dann nacheinander eingelesen werden und mit dem Suchwort überprüft werden. Gibts eine Fundstelle, so wird die Seite in einem weiteren Feld gespeichert. Sind alle Seiten gescannt, wird das Resultat in einer Tabelle ausgegeben...
http://home.media-n.de/13881/suchmaschine.html
Nun wird ja jeweils die ganze Datei eingelesen, was mit unter - je nach Verbindung - recht lange dauern kann (5-20 Sekunden bei mir). Es würde im Prinzip aber reichen, wenn nur ein bestimmter Teil der Datei eiungelsen wird - bsp von <body> bis </body> oder ein gewählter META Tag oder der gleichen.
Kann ich hXMLHttpRequest() noch einen Parameter mitgeben, der es mir erlaubt einen solchen Bereich zu definieren? Theoretisch wird auch reichen: Lese von Zeile 5 bis 15 oder so, also nicht Bereich durch HTML Tags definieren, sondern durch Zeilen...
Und mein 3tes Problem, wenn ich mit Opera8 eine Suche starte, stürzt dieser ab :-/ Offline habe ich dieses Problem nicht, sondern nur im Web. Woran könnte das liegen?
Mit freundlichem Gruß
Micha
-
Hallo derletztekick,
ich habe ersmal eine verständnis Frage, warum wird diese XML Datei nicht als solche im Browser angezeigt, sondern als TXT Datei angezeigt?
http://home.media-n.de/13881/keywords.xml→ text/plain
Und mein 3tes Problem, wenn ich mit Opera8 eine Suche starte, stürzt dieser ab :-/ Offline habe ich dieses Problem nicht, sondern nur im Web. Woran könnte das liegen?
An einem Bug. (Hilft dir das? ;-))
Grüße
Roland-
Hallo Roland,
→ text/plain
Kann ich das beeinflussen oder muss media-n.de das einstellen?
Und mein 3tes Problem, wenn ich mit Opera8 eine Suche starte, stürzt dieser ab :-/ Offline habe ich dieses Problem nicht, sondern nur im Web. Woran könnte das liegen?
An einem Bug. (Hilft dir das? ;-))
Jein, es sei denn, es gibt keine Möglichkeit diesen zu umgehen ;-)
Mit freundlichem Gruß
Micha
-
-
Hallo Micha
ich habe ersmal eine verständnis Frage, warum wird diese XML Datei nicht als solche im Browser angezeigt, sondern als TXT Datei angezeigt?
http://home.media-n.de/13881/keywords.xmlWeil der Server sie als "text/plain" ausliefert.
Wenn ich sie offline von meiner Festplatte lade, funktionierts...
Weil dort die Dateiendung und nicht der HTTP-Header zur Bestimmung des
Contenttypes verwendet wird.Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo Detlef,
Weil der Server sie als "text/plain" ausliefert.
Daraus schließe ich, das nur media-n dies einstellen kann und ich keinen Einfluss darauf habe - richtig?
Mit freundlichem Gruß
Micha-
Hallo Micha
Daraus schließe ich, das nur media-n dies einstellen kann und ich keinen Einfluss darauf habe - richtig?
Wenn dein Hoster einen Apache verwendet und die Verwendung der .htaccess erlaubt,
dann kannst du den Typ selbst hinzufügen.Scrolle mal bei http://de.selfhtml.org/servercgi/server/htaccess.htm#browsing
ein wenig weiter. Dort findest du AddType.Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo Detlef,
Wenn dein Hoster einen Apache verwendet und die Verwendung der .htaccess erlaubt,
dann kannst du den Typ selbst hinzufügen.Media-N ist mein Internetanbieter und dieser stellt - wie bspw. auch T-Online - seinen Kunden ein wenig Webspace zur Verfügung. htaccess wird wohl nicht unterstützt.
Ich habe folgendes eingetragen:
AddType application/xml .xml
So habe ich es zumindest verstanden. Das Ergebnis ist jedoch das selbe - text/plain...
Mit freundlichem Gruß
Micha-
Hallo Micha,
Media-N ist mein Internetanbieter und dieser stellt - wie bspw. auch T-Online - seinen Kunden ein wenig Webspace zur Verfügung. htaccess wird wohl nicht unterstützt.
Korrekt, denn deren Inhalt dürfte man nicht sehen: http://home.media-n.de/13881/.htaccess
Grüße
Roland-
Hallo Roland,
Korrekt, denn deren Inhalt dürfte man nicht sehen: http://home.media-n.de/13881/.htaccess
Hehe stimmt, sonst wäre der Sinn irgendwie verloren...
Gut, dann muss ich da mal anrufen.
Zu meinen anderen beiden Problemen noch Lösungen?
Mit freundlichem Gruß
Micha
-
-
-
-
-
-
Hi,
Kann ich hXMLHttpRequest() noch einen Parameter mitgeben, der es mir erlaubt einen solchen Bereich zu definieren? Theoretisch wird auch reichen: Lese von Zeile 5 bis 15 oder so, also nicht Bereich durch HTML Tags definieren, sondern durch Zeilen...
Das Argument für XMLHttpRequest() ist eine URI, d.h. Du kannst da auch Argumente mitgeben. Ja, das heißt auch, das es für Deine Zwecke nicht wirklich paßt.
Wenn Du das kommerziel nutzen wolltest würde ich anbieten Oliver Garcías Suchmaschine (die SelfHTML-Offlinesuchmaschine) von ihm anpassen zu lassen. Ich kenne aber seine Preise nicht.Also selber bauen:
- Sammel einen Inverted Index zusammen
- kleister Javascript drum: ein Array draus machen
- durchsuch' dann das Array
- Ausgabe der gefundenen Vorkommen.
Ich bin gerade dabei einen Artikel darüber zu schreiben. Wenn Du soviel Geduld hast, kannst Du das ja abwarten. Habe aber keine Ahnung wie lange das dauert, bis der öffentlich wird Ich habe nämlich keine Website mehr, seit T-Online meiner kleinen Schwester nahegelegt hatte, ihre Privatseite zu leeren: Traffic auf 1GiB begrenzt mit teuren MB-Preisen ohne gleichzeitig die Mittel zur Verfügung zu stellen diese Begrenzung zu überprüfen oder gar einhalten zu können ist da ein gutes Argument. Und etwas gegen Bares anzumieten, dafür sind wir beide viiiel zu geizig ;-)
so short
Christoph Zurnieden
-
Hallo Christoph,
Das Argument für XMLHttpRequest() ist eine URI, d.h. Du kannst da auch Argumente mitgeben. Ja, das heißt auch, das es für Deine Zwecke nicht wirklich paßt.
Schade, das ich die Zeilen (oder einen Bereich) nicht begrenzen kann - zumindest nicht beim einlesen. Liegt die Datei erstmal als STRING vor, kann ich natürlich diverse Bereiche rauspicken mit substring und indexOf...
Wenn Du das kommerziel nutzen wolltest würde ich anbieten Oliver Garcías Suchmaschine (die SelfHTML-Offlinesuchmaschine) von ihm anpassen zu lassen.
Nein, ich will es nicht kommerziel nutzen und letztlich auch selbst machen ;-)
Also selber bauen:
- Sammel einen Inverted Index zusammen
- kleister Javascript drum: ein Array draus machen
- durchsuch' dann das Array
- Ausgabe der gefundenen Vorkommen.
Das mach ich ja indirekt. Okay, die Suchwörter müssen im Kontext irgendeiner Seite vorkommen - das erübrigt das Array aber ansonsten trifft das meine Vorgehensweise. Mein zweiter Ansatz war über die XML Datei, da ich aber scheinbar keine XML Unterstüzung habe...
Des weiteren wäre es so nötig, die Datei immer von Hand anzupassen und auf den gegenwärtigen Stand zu bringen - bei einer Volltextsuche erübrigt sich die Arbeit ja auch, was ich eigentlich als vorteilhaft empfinde.
Ich bin gerade dabei einen Artikel darüber zu schreiben. Wenn Du soviel Geduld hast, kannst Du das ja abwarten.
Über das Suchen mit Hilfe von JavaScript oder allg. über XMLHttpRequest()?
Und etwas gegen Bares anzumieten, dafür sind wir beide viiiel zu geizig ;-)
Naja, derletztekick.com ist ja bezahlte Webspace. Ich lager nur meinen LEJS auf der media-n Seite aus - das aber schon immer.
Mit freundlichem Gruß
Micha-
Hi,
Schade, das ich die Zeilen (oder einen Bereich) nicht begrenzen kann - zumindest nicht beim einlesen. Liegt die Datei erstmal als STRING vor, kann ich natürlich diverse Bereiche rauspicken mit substring und indexOf...
Ich hätte da ja eher die Rückgabe von XmlHttpRequest genutzt und den erzeugten Baum mittels DOM geparsed. Aber gut, jeder wie's ihm gefällt ;-)
[...] und letztlich auch selbst machen ;-)
_Das_ ist hier ein _sehr_ gutes Argument! ;-)
Also selber bauen:
- Sammel einen Inverted Index zusammen
- kleister Javascript drum: ein Array draus machen
- durchsuch' dann das Array
- Ausgabe der gefundenen Vorkommen.
Das mach ich ja indirekt.
Direkt ist jedoch günstiger.
Des weiteren wäre es so nötig, die Datei immer von Hand anzupassen und auf den gegenwärtigen Stand zu bringen - bei einer Volltextsuche erübrigt sich die Arbeit ja auch, was ich eigentlich als vorteilhaft empfinde.
Aber mit dem sehr hohem Preis der Langsamkeit, die Dir auf den Senkel geht. Sonst hättest Du ja auch nicht gefragt, wie's schneller funktioniert, gelle? ;-)
Das mit dem regelmäßigen Anpassen ist kein Problem, da Du ja nur statische Seiten durchsuchst (ich habe das nicht untersucht, schließe es nur daraus, das Du ansonsten Deine Suche mit Sicherheit serverseitig implementiert hättest). Bei jeder Deiner Änderungen läßt Du eben den Indexer über Deine lokale Kopie laufen und lädst den I.I. dann einfach mit rauf.
Ein gewisses Problem ist die Phrasensuche, wäre aber auch lösbar.Über das Suchen mit Hilfe von JavaScript oder allg. über XMLHttpRequest()?
Über eine Offline-Katalogsuche mit Javascript. Mit XmlHttpRequest() hatte ich nie ... halt, stimmt nicht, einmal doch: ich hatte mal ein Frontend für g-brief mit Mozilla in XUL gebastelt. Da hatte ich mir so den ansonsten nötigen Reload für die PDF Rückgabe gespart und konnte auch noch eine Adressen-DB live auslesen.
XmlHttpRequest() hat aber auch den entscheidenden Nachteil, das der IE es mit ActiveX implementiert hat. Bei Javascript kann man ja noch mit relativ hoher Wahrscheinlichkeit davon ausgehen, das es eingeschaltet ist, bei ActiveX liegt der Fall jedoch umgekehrt.so short
Christoph Zurnieden
-
Hallo,
Ich hätte da ja eher die Rückgabe von XmlHttpRequest genutzt und den erzeugten Baum mittels DOM geparsed. Aber gut, jeder wie's ihm gefällt ;-)
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen, die Du da ansprichst. Ist mir aber, da ich nciht so DOM bewandert bin^^, seiner Zeit nicht in den Sinn gekommen. IndexOf und substr fallen mir zum suchen immer auf anhieb ein. Letztlich sollte es - zumindest was die Geschwindigkeit angeht - keine Vor/Nachteile mit sich bringen es so oder so zu machen. Wenn ich nachher mal Zeit habe, kann ich es ja mal versuchen. Damit wäre zumindest der Zugrif auf ein bestimmtest Element (oder wie auch immer sich das dann schimpft) möglich. Das laden der gesamten Datei wird dabei aber nicht verhindert.
Aber mit dem sehr hohem Preis der Langsamkeit, die Dir auf den Senkel geht. Sonst hättest Du ja auch nicht gefragt, wie's schneller funktioniert, gelle? ;-)
Ja, indirekt stimmt das. Ich wollte es aber beschleunigen, in dem ich "verhindere", das unnötige Teile der einzelnen Seiten geladen werden. Die Geschwindigkeit ist ja Maßgeblich durch die InternetVerbindung gegeben. Es dauert - so vermute ich mal - genau SO lange, als würde man sich die zu durchsuchenden Seiten nacheinander im Browser ansehen plus ein paar 10tel Sekunden, die das Script an sich noch benötigt.
[...] das Du ansonsten Deine Suche mit Sicherheit serverseitig implementiert hättest).
Korrekt!
Bei jeder Deiner Änderungen läßt Du eben den Indexer über Deine lokale Kopie laufen und lädst den I.I. dann einfach mit rauf.
Ein gewisses Problem ist die Phrasensuche, wäre aber auch lösbar.Bitte?
Über eine Offline-Katalogsuche mit Javascript.
hmm, offline funktioniert die Suche recht schnell, das ist also weniger das Problem. Ich weiss aber nicht wie es aussieht, wenn man "viele" Dateien scannt.
Mit freundlichem Gruß
Micha-
Hi,
Ich hätte da ja eher die Rückgabe von XmlHttpRequest genutzt und den erzeugten Baum mittels DOM geparsed. Aber gut, jeder wie's ihm gefällt ;-)
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen, die Du da ansprichst. Ist mir aber, da ich nciht so DOM bewandert bin^^,
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
seiner Zeit nicht in den Sinn gekommen. IndexOf und substr fallen mir zum suchen immer auf anhieb ein. Letztlich sollte es - zumindest was die Geschwindigkeit angeht - keine Vor/Nachteile mit sich bringen es so oder so zu machen.
Theoretisch wäre die DOM-Suche schneller. Aber Flaschenhals ist I/O sprich das Laden der Dateien, da spielt der eigentliche Stringsuchalgorithmus in der Datei keine wesentliche Rolle mehr (vorrausgesetzt natürlich es ist kein "Bogosearch" o.ä. ;-), da hast Du natürlich Recht.
Aber mit dem sehr hohem Preis der Langsamkeit, die Dir auf den Senkel geht. Sonst hättest Du ja auch nicht gefragt, wie's schneller funktioniert, gelle? ;-)
Ja, indirekt stimmt das. Ich wollte es aber beschleunigen, in dem ich "verhindere", das unnötige Teile der einzelnen Seiten geladen werden.
Ja, deshalb ja mein Vorschlag, dieses Laden vollständig zu unterbinden bzw extrem zu reduzieren.
Die Geschwindigkeit ist ja Maßgeblich durch die InternetVerbindung gegeben. Es dauert - so vermute ich mal - genau SO lange, als würde man sich die zu durchsuchenden Seiten nacheinander im Browser ansehen plus ein paar 10tel Sekunden, die das Script an sich noch benötigt.
Es geht ein klein wenig schneller, da nichts gerendert werden muß, aber das ist nicht wesentlich: größter Zeitfresser ist und bleibt das Laden der Datei vom Server.
Ein gewisses Problem ist die Phrasensuche, wäre aber auch lösbar.
Bitte?Du kannst ja jetzt dank Volltextsuche auch nach Teilsätzen suchen. Sei "Dies ist ein vollständiger Satz, der sogar einen Nebensatz hat." das Beispiel, so kannst Du nicht nur nach einzelnen Worten sondern auch nach mehreren Worten mit gegebener Reihenfolge suchen. "ein vollständiger Satz" findet obigen Satz, "vollständiger ein Satz" findet ihn nicht.
In einem Inverted Index stehen nur einzelne Worte drin, benebest einer Liste, in welcher Datei diese Worte vorkommen. Du kannst also so maximal feststellen, welche Datei alle Worte enthält, aber nicht in welcher Reihenfolge. Wenn Du nun aber neben dem nacktem Fundort auch die die laufende Nummer des Wortes (z.B. "wort" ist in Datei "yxz" an 23. Stelle) im Inverted Index speicherst, hast Du auch die Reihenfolge und damit ist dann natürlich auch eine Phrasensuche möglich.
Oder Du behältst Deine Mimik mit der Volltextsuche und wendest die bei allen Dateien an, in denen alle Worte vorkommen.Über eine Offline-Katalogsuche mit Javascript.
hmm, offline funktioniert die Suche recht schnell, das ist also weniger das Problem. Ich weiss aber nicht wie es aussieht, wenn man "viele" Dateien scannt.Im Selfhtml-8.1 Paket gibt es 1446 HTML-Dateien, ist auch mein Testbed, viel Spaß damit ;-)
so short
Christoph Zurnieden
-
Hallo,
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen..
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
Ja, wäre es, obwohl das eigentlich in diesem Fall nicht so wichtig wäre... Mal sehen...
Du kannst ja jetzt dank Volltextsuche auch nach Teilsätzen suchen. Sei "Dies ist ein vollständiger Satz, der sogar einen Nebensatz hat." das Beispiel, so kannst Du nicht nur nach einzelnen Worten sondern auch nach mehreren Worten mit gegebener Reihenfolge suchen. "ein vollständiger Satz" findet obigen Satz, "vollständiger ein Satz" findet ihn nicht....
Um das Suchen von mehreren Wörtern habe ich mich noch nicht befasst. Daher würde mein Script auch die Kombination "ein Satz" nicht finden. Grund ist, das es erstmal schnell(er) werden muss, bevor ich auch soetwas zurückgreifen würde. auch logische Verknüpfungen "ein+satz" oder so gehen nicht...
Um mehrere Suchbegriffe zu zulassen müsste ich die Trefferspeicherung wohl etwas anders gestalten. Die übergebenen Suchwörter würde ich dabei einfach in einem Array ablegen und mit Hilfe einer Schleife jeden einzelnen INDEX mit dem String prüfen.Dann steht für jeden einzelnen Treffer die Daten im Ergebnisfeld. Diese müsste ich erneut Prüfen. Habe ich bspw drei Wörter eingegeben, dann muss im TrefferArray auch dreimal die entsprechende HTML Datei drin stehen - wenn weniger, dann ist es kein Treffer usw...
Sowas loht aber erst, wenns wie gesagt schneller geworden ist.Im Selfhtml-8.1 Paket gibt es 1446 HTML-Dateien, ist auch mein Testbed, viel Spaß damit ;-)
Hallo?! Die müsste ich von Hand zunächst eintragen ;-)
Aber: ich habe mal die Ordner Quellen, Projekt, PHP, Navigation und deren Unterordner eingetragen - macht 56 Dateien. Als suchbegrig diente "html", da der immer vorkommt (<html>) das Ergebnis wurde in einem Bruchteil einer Sekunde ohne nennenswerte Verzögerung ausgegeben...
Mit freundlichem Gruß
Micha-
Hi,
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen..
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
Ja, wäre es, obwohl das eigentlich in diesem Fall nicht so wichtig wäre... Mal sehen...Ich würd's schon machen, ist einfacher nachher. Das erworbene Wissen kannst Du auch später immer gebrauchen.
Um das Suchen von mehreren Wörtern habe ich mich noch nicht befasst. Daher würde mein Script auch die Kombination "ein Satz" nicht finden. Grund ist, das es erstmal schnell(er) werden muss, bevor ich auch soetwas zurückgreifen würde. auch logische Verknüpfungen "ein+satz" oder so gehen nicht...
Ja, das wird so, wie Du das jetzt implementiert hast nix, aber so weit warst Du ja schon selber ;-)
Das der Flaschenhals das Laden der Dateien und nicht das Durchsuchen ist, hast Du auch schon festgestellt. das heißt einerseits, das Du ruhig Deine Suche verfeinern kannst, denn das hat mit dem Problem "Lahmarschigkeit" erst mal nix zu tun und zum anderen, das Du es schlicht vermeiden muß Dateien überhaupt erst zu laden.
Das kannst Du, in dem Du die Dateien _vorher_ durchsuchst und das Ergebnis in die Suche direkt einbaust. Ene gute Methode dafür ist der beschriebene Inverted Index. Da ist einerseits sehr viel Information drin, andererseits aber auch kein Volltext.
Der Inverted Index der HTML-Seiten vom Selfhtml-8.1 Paketes hat bei mit rund 25.000 Einträge. Unbereinigt aber schon alles tolower() gesetzt. Ein rundes MiB an Daten. Das ist ziemlich viel, läßt sich aber sehr gut aufteilen, da bereits sortiert. Selbst bei Teilstringsuche oder gar RegEx bräuchtest Du nur runde 10-12 Dateien zu laden, je nachdem, wie Du aufgeteilt hast. Bei exakter Vollwortsuche bräuchtest Du sogar nur eine laden: wenn Du den I.I. z.B. nach dem Alphabet aufgeteilt hast, mußt Du nach dem Wort "Meningitis" natürlich nur in "m.js" suchen und nicht erst alle von a-n durchklappern.
Also im Höchstfall 12 Dateien laden mit rund 1 MiB Volumen anstatt 1446 Dateien mit über 10 MiB Volumen einzeln zu laden und zu durchsuchen.
Die Größe des Inverted Index steigt auch nur asymptotisch gegen die Grenze bei etwa 100.000*n, wobei "n" die Anzahl der natürlichen Sprachen des Datensatzes ist. Wenn Du also z.B. den deutschsprachigen Gutenbergmirror bei spiegel.de indizieren würdest, kämst Du auf maximal so um die 100.000 Einträge im Inverted Index, bei weit über einem GiB an Daten. Noch besser: indizierst Du auch noch den englischsprachigen Gutenbergmirror dazu kommst Du auf rund 200.000 Einträge bei einigen zig Gigabyte an Daten. Skaliert also gut, oder? ;-)Um mehrere Suchbegriffe zu zulassen müsste ich die Trefferspeicherung wohl etwas anders gestalten. Die übergebenen Suchwörter würde ich dabei einfach in einem Array ablegen und mit Hilfe einer Schleife jeden einzelnen INDEX mit dem String prüfen.
Naja, ich glaube _das_ ist Dein kleinstes Problem ;-)
Dann steht für jeden einzelnen Treffer die Daten im Ergebnisfeld. Diese müsste ich erneut Prüfen. Habe ich bspw drei Wörter eingegeben, dann muss im TrefferArray auch dreimal die entsprechende HTML Datei drin stehen - wenn weniger, dann ist es kein Treffer usw...
Naja, das ist dann wieder eine Frage der Gewichtung, aber das kommt dann wirklich später.
Im Selfhtml-8.1 Paket gibt es 1446 HTML-Dateien, ist auch mein Testbed, viel Spaß damit ;-)
Hallo?! Die müsste ich von Hand zunächst eintragen ;-)Keine ordentliche Shell zur Hand? Perl? Sonstwas an Skriptsprachen für'n Einzeiler?
Bist auf Windows, was? ;-)Aber: ich habe mal die Ordner Quellen, Projekt, PHP, Navigation und deren Unterordner eingetragen - macht 56 Dateien. Als suchbegrig diente "html", da der immer vorkommt (<html>) das Ergebnis wurde in einem Bruchteil einer Sekunde ohne nennenswerte Verzögerung ausgegeben...
56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
so short
Christoph Zurnieden
-
Hallo,
»» Hi,
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen..
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
Ja, wäre es, obwohl das eigentlich in diesem Fall nicht so wichtig wäre... Mal sehen...Ich würd's schon machen, ist einfacher nachher. Das erworbene Wissen kannst Du auch später immer gebrauchen.
Wenn ich es denn erwerben würde^^
https://forum.selfhtml.org/?t=107053&m=664594
Wie dort beschrieben kann ich nicht mit getElement(s)by... auf Teile des Strings zugreifen......Du es schlicht vermeiden muß Dateien überhaupt erst zu laden.
Dazu müsste ich meinen bisherigen Ansatz natürlich überdenken, obwohl ich die Idee so erstmal als recht gut eingestufft habe ;-)
Das kannst Du, in dem Du die Dateien _vorher_ durchsuchst und das Ergebnis in die Suche direkt einbaust. Ene gute Methode dafür ist der beschriebene Inverted Index. Da ist einerseits sehr viel Information drin, andererseits aber auch kein Volltext.
Das sollte ich mir dann wohl doch mal ansehen... SelfHTML ist da zwar nicht das beste Beispiel, da der Umfang doch recht groß ist aber vll liefert mir ja Google noch was brauchbares... Mit ist da momentan der Aufbau noch nicht ganz klar. Okay, die Suchwörter kommen in ein Feld oder vgl.bares aber wo/wie legst Du dann die Trefferliste bzw Seiten fest?
keywords[0] = new Array ('Wort1', 'Wort2', 'Wort3', 'Wort4', ... , 'Wortn', seite.html'); ?
Das hätte in der Konstellation den Nachteil, das ich für jede Seite ein INDEX keywords[] anlegen müsste - sicher nicht Sinn der Sache.
Eine Zweite möglichkeit wäre, jeden Suchbegriff zu spezifizieren und den Dateien zuweisen
keyword[0] = new Array ('Wort1', 'seite1.html', 'seite2.html');
keyword[1] = new Array ('Wort2', 'seite2.html', 'seite4.html', 'seite5.html');
...Also jedes Wort den zutreffenden Seiten zuwesien. Ein asso. Array könnte das vll noch vereinfachen - müsste man dann mal sehen aber elegant finde ich das auch nciht ;-)
Im Selfhtml-8.1 Paket gibt es 1446 HTML-Dateien, ist auch mein Testbed, viel Spaß damit ;-)
Hallo?! Die müsste ich von Hand zunächst eintragen ;-)Keine ordentliche Shell zur Hand? Perl? Sonstwas an Skriptsprachen für'n Einzeiler?
Bist auf Windows, was? ;-)Ja Windows^^ XAMPP läuft zwar aber so richtig Lust hatte ich nicht, mir ein PHP Script zu schreiben und ein EINzeiler wäre das bei mir auch nicht geworden ;-)
56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
Das sind aber 7mal mehr als bisher (möchte nicht wissen, was das an Zeit im Netz gekostet hätte) :-)
Mit freundlichem Gruß
Micha-
Hi,
Wenn ich es denn erwerben würde^^
https://forum.selfhtml.org/?t=107053&m=664594
Wie dort beschrieben kann ich nicht mit getElement(s)by... auf Teile des Strings zugreifen...Autsch, ja, meine Schuld, hab' ganz vergessen das Dein Server nicht auf XML eingestellt ist, 'tschuldigung.
...Du es schlicht vermeiden muß Dateien überhaupt erst zu laden.
Dazu müsste ich meinen bisherigen Ansatz natürlich überdenken, obwohl ich die Idee so erstmal als recht gut eingestufft habe ;-)Ach, da wirst Du in Deinem Leben noch so manche vermeintlich gute Idee wegschmeißen müssen, glaub's so einem altem Sack wie mir ruhig ;-)
Das kannst Du, in dem Du die Dateien _vorher_ durchsuchst und das Ergebnis in die Suche direkt einbaust. Ene gute Methode dafür ist der beschriebene Inverted Index. Da ist einerseits sehr viel Information drin, andererseits aber auch kein Volltext.
Das sollte ich mir dann wohl doch mal ansehen... SelfHTML ist da zwar nicht das beste Beispiel, da der Umfang doch recht groß istEigentlich nicht, das ist eine schöne Größe zum probieren.
aber vll liefert mir ja Google noch was brauchbares... Mit ist da momentan der Aufbau noch nicht ganz klar. Okay, die Suchwörter kommen in ein Feld oder vgl.bares aber wo/wie legst Du dann die Trefferliste bzw Seiten fest?
keywords[0] = new Array ('Wort1', 'Wort2', 'Wort3', 'Wort4', ... , 'Wortn', seite.html'); ?
Das hätte in der Konstellation den Nachteil, das ich für jede Seite ein INDEX keywords[] anlegen müsste - sicher nicht Sinn der Sache.
Eine Zweite möglichkeit wäre, jeden Suchbegriff zu spezifizieren und den Dateien zuweisenkeyword[0] = new Array ('Wort1', 'seite1.html', 'seite2.html');
keyword[1] = new Array ('Wort2', 'seite2.html', 'seite4.html', 'seite5.html');
...Ja, das ist ein Inverted Index. Drum heißt er ja auch _inverted_ Index ;-)
Die Dateien kommen da übrigens natürlich nicht mehr als vollständige Pfade rein, das wird schnell zuviel, sondern als Nummern. Diese Nummern werden dann in einem Extraarray wieder aufgelöst:
1,/pfad/zur/datei/foo
2,/pfad/zur/datei/bla
3,/pfad/zur/datei/die/nummer/drei/sein/soll
4,/pfad/dingensAlso jedes Wort den zutreffenden Seiten zuwesien. Ein asso. Array könnte das vll noch vereinfachen
Nein, einfacher geht's nicht mehr. Solltest Du wider Erwarten trotzdem etwas besseres finden: nur her damit!
- müsste man dann mal sehen aber elegant finde ich das auch nciht ;-)
Nicht elegant? Wie soll's denn noch eleganter gehen?
Na, _das_ möcht' ich sehen! ;-)Ja Windows^^ XAMPP läuft zwar aber so richtig Lust hatte ich nicht, mir ein PHP Script zu schreiben und ein EINzeiler wäre das bei mir auch nicht geworden ;-)
Ja, das ist das Problem ohne vernünftige Shell oder wenigstens Perl.
Beim neuen MacOS hat man sie jetzt, braucht sie aber im Grunde genommen nicht, bei Unix hat man sie und braucht sie auch, nur bei Windows, da hat man keine braucht sie aber.Du solltest Dir wenigsten ActivPerl besorgen, Perl erleichtert so einiges. Grundkenntnise in Perl sind eh zu empfehlen.
Was so langsam hoch kommt und die Stelle von Perl einzunehmen scheint ist Python. Aber bei Python kannst Du nicht mehr "schlampig rumhacken" wie bei PHP oder kryptisch werden wie bei Perl, da wird Wert auf gepflegtes Äußeres udn deutliche Aussprache gelegt. Das schmeckt nicht unbedingt jedem.
Mir übrigens auch nicht so recht ;-)56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
Das sind aber 7mal mehr als bisher (möchte nicht wissen, was das an Zeit im Netz gekostet hätte) :-)Ja, das meinte ich damit: Bottleneck ist das Laden selber.
Ich habe hier runde 50.000 HTML-Seiten (falsch: Pfade mit dem Teilstring ".html", wie gleich zu sehen) auf der Platte (49411 um genau zu sein und mit ziemlich genau 400 MiB), die kann ich ja mal mit Bordmitteln nach dem String "html" (nur kleingeschrieben) durchsuchen.$ sum=0;for i in
locate .html| grep -v ' ';do j=/usr/local/bin/sizeof $i; sum=$[$sum+$j];done;echo $sum
419272273$ time for i in
locate .html| grep -v ' '; do fgrep -q html $i;done[22 Fehler: war entweder ein Verzeichnis mit ".html" drin oder kein Zugriff erlaubt. Rund 300 kib Gesamtgröße]
real 10m19.340s
user 1m25.630s
sys 4m0.430sAuf einem Duron 1200 mit 512 MiB RAM (die waren aber schon ziemlich voll: zwischendurch kam hin und wieder ein Paging dazwischen). 'ne ganz schön lahme Platte hab' ich wohl. Gut, war ja auch billig gewesen ;-)
Also, wie gesagt: vermeide es so weit als möglich Dateien zu holen, dann klappt's auch mit der Suche Online.
so short
Christoph Zurnieden
PS:
Falls sich jemand über die etwas merkwürdige Größenmessung wundert: die Bash beschwert sich irgendwann numal über eine zu lange Argumentliste und bevor ich mir die jetzt auch noch zurechtfummel ... ;-)
CZ-
Hallo Christoph,
Wenn ich es denn erwerben würde^^
https://forum.selfhtml.org/?t=107053&m=664594
Wie dort beschrieben kann ich nicht mit getElement(s)by... auf Teile des Strings zugreifen...Autsch, ja, meine Schuld, hab' ganz vergessen das Dein Server nicht auf XML eingestellt ist, 'tschuldigung.
Und ich dachte schon, ich würde mich zu blöd anstellen ;-)) Das es mit XML Dateien funktioniert, habe ich bereits bemerkt. Daher war einer meiner drei Fragen, warum die XML Datei nicht als solche ausgeliefert wird. Würde sie nicht als text/plain kommen, hätte ich mit Hilfe einer Checkbox den User vor die Wahl gestellt, ob er eine IndexSuche oder eine VolltextSuche möchte. Bei der IndexSuche hätte er dann nur die XML geladen, in der ich verschiedene Suchbegriffe selbst definiert hätte - lokal funktioniert das auch, aber media-n macht mir da ja ein Strich durch die Rechnung. Dann müsste zwar immer noch eine Datei geladen werden, aber was ist das schon im Vergleich zu 8 oder mehr?
Auch sonst sollte es meiner Meinung nach nur möglich sein mit getElement(s)By... auf einen bestimmten Teil zu zugreifen, wenn es sich um eine XML Datei handelt. Einen Weg, bestimmte Elemente anzusprechen wenn es sich um eine nicht XML Datei handelt habe ich (@localhost) noch nciht gefunden.Ach, da wirst Du in Deinem Leben noch so manche vermeintlich gute Idee wegschmeißen müssen, glaub's so einem altem Sack wie mir ruhig ;-)
Da ich eigentlich immer nur ein wenig probiere und "spiele" dauert ein Script manchmal länger als es nachher aussieht. Von daher suche ich natürlich primär eine Lösung ohne das bereits erstellte vollständig über den Haufen zu werfen - ich denke das wird auch einem alten Hasen nicht anders gehen?
keyword[0] = new Array ('Wort1', 'seite1.html', 'seite2.html');
keyword[1] = new Array ('Wort2', 'seite2.html', 'seite4.html', 'seite5.html');
...Ja, das ist ein Inverted Index. Drum heißt er ja auch _inverted_ Index ;-)
Aha, dann lag ich ja gar nicht so falsch - wer hätte das gedacht ;-)
Mal sehen, wie und ob ich das mache. Immerhin habe ich nur ganze 8 Seiten, die zu durchsuchen wären (das meinte ich mit probieren und spielen) - ob das Lohnt?Du solltest Dir wenigsten ActivPerl besorgen, Perl erleichtert so einiges. Grundkenntnise in Perl sind eh zu empfehlen.
Sind sie? Habe im winter gerade mal ein bischen mit PHP was gemacht, zuviel Veränderung sind auch in jungen Jahren nicht vorteilhaft^^
Mir wäre es da lieber, wenn ich das eine erstmal etwas perfektionieren könnte, als alles ein wenig anzuschneiden. Und JavaScript war letztlich nicht so schwer - zumindest das, was _ich_ kann. In der Schule hatte ich die Grundlagen in Java, so das der "Umstieg" nicht so schwer war (Syntax usw).
Der ObjektOrientiereAnsatz wurde uns jedoch nicht vermittelt, so dass ich mich hier auch schwer tue, in JS einen solchen Ansatz zu finden. Letztlich läuft es hier immer auf try & error aus - was auch nicht unbedingt schlecht ist aber mit unter viel Zeit in Anspruch nimmt...56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
Ja, das meinte ich damit: Bottleneck ist das Laden selber.Also, wie gesagt: vermeide es so weit als möglich Dateien zu holen, dann klappt's auch mit der Suche Online.
Ja, als offline Suche ist es bereits okay (meiner Meinung nach)
Wie hier beschrieben:
https://forum.selfhtml.org/?t=107053&m=664633Habe ich mit meinem JS mal die Dokumentation von SelfHTML 8.0 gescannt. In weniger als 10 Sekunden war das Ergebnis da - zufriedenstellend, wie ich finde! Online natürlich eine Katastrophe, wenn man das hochrechnen würde...
Wenn ich mir Deine Argumente mal so zu Herzen nehme, werde ich wohl mein bisherigen Ansatz ins Archiv tuen und von vorn anfangen. Vll hat ja bald einer die bahnbrechende Idee, es zu verbessern.
Mit freundlichem Gruß
Micha-
Hi,
Bei der IndexSuche hätte er dann nur die XML geladen, in der ich verschiedene Suchbegriffe selbst definiert hätte -
Und warum nimmst Du dafür keine externe Javasript-Datei? Muß natürlich nicht unbedingt extern sein, wäre dann nur einfacher zu ändern.
Oder, damit Du auch ein wenig Fachchinesisch zum Angeben hast: skalierbarer.Auch sonst sollte es meiner Meinung nach nur möglich sein mit getElement(s)By... auf einen bestimmten Teil zu zugreifen, wenn es sich um eine XML Datei handelt. Einen Weg, bestimmte Elemente anzusprechen wenn es sich um eine nicht XML Datei handelt habe ich (@localhost) noch nciht gefunden.
Es geht: mit Mozilla. Da kannst Du einen so empfangenen String parsen, eine Art String2XML sozusagen. Da aber nicht portabel genügt es nicht Deinen Vorgaben.
Da ich eigentlich immer nur ein wenig probiere und "spiele" dauert ein Script manchmal länger als es nachher aussieht. Von daher suche ich natürlich primär eine Lösung ohne das bereits erstellte vollständig über den Haufen zu werfen
Naja, macht man natürlich nie gerne. Aber mitunter ist ein "alles in die Tonne" einfach nötig.
- ich denke das wird auch einem alten Hasen nicht anders gehen?
Da hast Du etwas mißverstanden: "alte Sack" != "alter Hase"! ;-)
Mal sehen, wie und ob ich das mache. Immerhin habe ich nur ganze 8 Seiten, die zu durchsuchen wären (das meinte ich mit probieren und spielen) - ob das Lohnt?
Selbstverständlich lohnt sich das rein gar nicht, aber das war ja auch nicht Deine Intention, oder habe diesmal ich da etwas mißverstanden?
Du solltest Dir wenigsten ActivPerl besorgen, Perl erleichtert so einiges. Grundkenntnise in Perl sind eh zu empfehlen.
Sind sie?Grundkenntnisse auf jeden Fall.
Mir wäre es da lieber, wenn ich das eine erstmal etwas perfektionieren könnte, als alles ein wenig anzuschneiden.
Ein Fachidiot zu werden, ist nicht besonders erstrebenswert. Lieber nix von allem als alles von nix zu wissen.
Auch ist PHP außerhalb von Webseiten nicht besonders verbreitet. Der Ersatz für Perl, wenn es sowas überhaupt gibt, ist im gewerblichem Bereich Python und _nicht_ wie allseits konstatiert PHP!Und JavaScript war letztlich nicht so schwer - zumindest das, was _ich_ kann. In der Schule hatte ich die Grundlagen in Java, so das der "Umstieg" nicht so schwer war (Syntax usw).
Und das obwohl Java und Javascript rein gar nix miteinander zu tun haben.
Es gibt nur eine handvoll Grundsysteme bei Programmiersprachen und die "handvoll" ist sogar wörtlich gemeint. Wenn Du von jedem System ein Beispiel in den Grundzügen kennengelernt kannst Du recht schnell alle anderen des Systems erlernen.
Aber vor allem ist es wichtig etwas über Algorithmen und Datenstrukturen zu wissen. Du hast jetzt die Datenstruktur des Inverted Index kennengelernt, bist sogar selber drauf gekommen. Das Prinzip des Inverted Index' kannst Du jetzt problemlos in alle Dir bekannten Sprachen portieren und wenn Du eine unbekannte Sprache hast, weißt Du schon _vorher_ genau, wonach Du in der Doku/Google/Newsgroup suchen/fragen mußt.Der ObjektOrientiereAnsatz wurde uns jedoch nicht vermittelt, so dass ich mich hier auch schwer tue, in JS einen solchen Ansatz zu finden.
Laß die anderen mit Buzzwords jonglieren, fall nicht drauf rein. Die meisten Leute, die mit dem Begriff "Objektorientierte Sprache" um sich werfen haben im Leben noch keine gesehen.
Letztlich läuft es hier immer auf try & error aus - was auch nicht unbedingt schlecht ist aber mit unter viel Zeit in Anspruch nimmt...
Deshalb ja auch mein Hinweis darauf, sich mehr mit Datenstrukturen und Algorithmen zu beschäftigen, damit man _weiß_ wonach man suchen muß. Das ist nämlich die häufigste Schwierigkeit, die ich nicht zuletzt an mir selber festgestellt habe.
Also, wie gesagt: vermeide es so weit als möglich Dateien zu holen, dann klappt's auch mit der Suche Online.
Habe ich mit meinem JS mal die Dokumentation von SelfHTML 8.0 gescannt. In weniger als 10 Sekunden war das Ergebnis da - zufriedenstellend, wie ich finde!
Und was sagt Dir dieser Test? Das es an Deiner Suche selber schonmal nicht liegt (Du solltest bei sowas auch untersuchen, ob es ein Wort, das garantiert nicht vorkommt ebenfalls korrekt behandelt), sondern an etwas anderem. Größert Unterschied zwischen On- und Offline ist die Ladezeit über's Netz. Somit ist also eine Optimierungsmöglichkeit, die Ladezeiten zu reduzieren. An dem Netz-Lag kannst Du nicht rütteln, also mußt Du dafür sorgen, das es einfach seltener vorkommt.
So sollte Deine Analyse idealerweise ausgesehen haben. Wahrscheinlich hätte fast jeder noch mal eben drübergeschaut, ob's nicht doch noch ein grober Schnitzer ist, aber im Endeffekt wär's das gewesen.
Dafür braucht es auch keinerlei intime Kenntnis einer Programmiersprache, es würde sogar rein gar nix nutzen, sonern Du benötigst grundlegendes Verständnis für die Vorgänge im Ganzen.
Aber: um T&E wirst Du auch so selten ganz herumkommen ;-)Wenn ich mir Deine Argumente mal so zu Herzen nehme, werde ich wohl mein bisherigen Ansatz ins Archiv tuen und von vorn anfangen. Vll hat ja bald einer die bahnbrechende Idee, es zu verbessern.
Das könnte sein, aber es ist schwer zu bezweifeln. Das hätte sonst schon einer in den letzten drei- bis viertausend Jahren getan.
Aber unmöglich ist natürlich nix! ;-)so short
Christoph Zurnieden
-
Hallo,
Und warum nimmst Du dafür keine externe Javasript-Datei?
Hat(te) keinen Grund, war mehr zum probieren...
- ich denke das wird auch einem alten Hasen nicht anders gehen?
Da hast Du etwas mißverstanden: "alte Sack" != "alter Hase"! ;-)
Hehe, wollte Dir nicht zu nahe treten.
...das war ja auch nicht Deine Intention, oder habe diesmal ich da etwas mißverstanden?
Nein hast Du nicht. Wollte nur sehen was möglich bzw. nicht möglich wäre. Das Problem, das man nur ein Wort suchen kann, habe ich nun doch noch gelöst, bevor ich mich gänzlich von der Idee löse. Um bei Deinem Bsp zu bleiben: "Das ist ein vollständiger Satz, mit einem Nebensatz" - die Suche nach: "vollständig Nebensatz" sollte nun zum Ziel führen.
In der Schule hatte ich die Grundlagen in Java, so das der "Umstieg" nicht so schwer war (Syntax usw).
Und das obwohl Java und Javascript rein gar nix miteinander zu tun haben.
Daher die Anführungszeichen ;-))
Laß die anderen mit Buzzwords jonglieren, fall nicht drauf rein. Die meisten Leute, die mit dem Begriff "Objektorientierte Sprache" um sich werfen haben im Leben noch keine gesehen.
Mein Wissen dazu ist auch nicht gerade berauschend, so dass dies noch eine Herausvorderung ist. Ob ich dabei alle "Fachwörter" nachher drauf habe, ist mir eigentlich egal. Ich sehe in der Kleinkariertheit, wenn einer Bspw. HTML-Befehle oder der gleichen sagt, keinen Sinn ihn deswegen zu Maßregeln, wie das machmal (hier) der Fall ist. Solange ich weiss, was wie funktioniert oder in welcher Konstellation etwas genau das macht, was ich brauche, reicht mir das - das mögen andere gern verbissener sehen...
Deshalb ja auch mein Hinweis darauf, sich mehr mit Datenstrukturen und Algorithmen zu beschäftigen, damit man _weiß_ wonach man suchen muß. Das ist nämlich die häufigste Schwierigkeit, die ich nicht zuletzt an mir selber festgestellt habe.
Ja, da muss ich Dir recht geben! Die ersten Geh-Versuche mit SlfHTML seiner Zeit waren schwer. Ich wusste zwar, was ich will aber solange ich die Suche nicht mit dem eigentlichen "Treffer" gefüttert hatte, kam ich zu keinem Ergebnis. Weiss ich aber erstmal, wie auch der Befehl zu meinem Problem heißt, ist es natürlich ein leichtes die Suche zu nutzen...
Und was sagt Dir dieser Test? Das es an Deiner Suche selber schonmal nicht liegt (Du solltest bei sowas auch untersuchen, ob es ein Wort, das garantiert nicht vorkommt ebenfalls korrekt behandelt), sondern an etwas anderem.
Ja, was agt mir das? Das die Idee für eine Offline Suche(maschine) okay ist und auch praktikabel. Größere Pakete würde ich aber trotzdem nicht durchsuchen lassen. Funktionier auch - die suche nach "Insektenspray" ergab Null treffer. Die suche nach "Michael" 11 Treffer. Opera8, FF1.0 und der InternetExplorer6 scheinen auch keine Probleme mit der Menge zu haben...
Das ist zumindest ein Teilerfolg (hätte ich nciht gedacht, das es funktioniert).Aber: um T&E wirst Du auch so selten ganz herumkommen ;-)
Ist in der Regel auch ne gute Art etwas zu lernen, zumindest bei solchen Hobbys.
Schöne Grüße
Micha-
Hi,
Hat(te) keinen Grund, war mehr zum probieren...
"Zum probieren" _ist_ ein guter Grund beim lernen!
Mein Wissen dazu ist auch nicht gerade berauschend, so dass dies noch eine Herausvorderung ist.
Wenn Dich Objektorientiertheit interessiert solltest Du mal in Modula reinschauen, Smalltalk und Objective-C.
Größere Pakete würde ich aber trotzdem nicht durchsuchen lassen.
Volltext wohl nicht, aber mit einem Index ist das durchaus kein Problem.
Na, dann noch weiterhin viel Vergnügen!
so short
Christoph Zurnieden
-
Hallo,
Na, dann noch weiterhin viel Vergnügen!
Danke, werd ich haben. Wenns Probleme gibt, werd ich mich schon melden^^
Mit freundlichem Gruß
Micha
-
-
-
-
Hallo,
56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
Okay, ich habe SelfHTML8.0 durchsucht (alle Dateien mit der Endung *.htm) das waren 1402 Datein.
Ein PHP Script ging wirklich schneller als erwartet...
Er hat nicht einmal 10 Sekunden für die VolltextSuche benötigt - ist das okay? Ich denke schon.
Suchwort war übrigens wieder "HTML", so dass das Script jede Datei als Treffer noch auflisten musste.
Mit freundlichem Gruß
Micha
-
-
Hallo,
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen..
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
Ich habs gerade mal versucht...
alert(request.responseText.getElementsByTagName('body'));
geht gar nicht wie ich gedacht hatte.wenn ich eine XML Datei einlese würde es mit:
request.responseXML.getElementsByTagName('name');
gehen, da ich keine XML Dateien einlese bekomme ich logischerweise einen Fehler. Wie soll ich mittels DOM auf einzelne Elemente zugreifen, die in request.responseText stehen?
Mit freundlichem Gruß
Micha
-
-
-
-
Hallo,
http://home.media-n.de/13881/suchmaschine.html
Nun wird ja jeweils die ganze Datei eingelesen, was mit unter - je nach Verbindung - recht lange dauern kann (5-20 Sekunden bei mir).
Deshalb würde ich spontan sagen, dass die Idee einer clientseitigen Suche in serverseitigen Dokumenten ... Unsinn ist. Man kann allerdings XMLHttpRequest wunderbar zusammen mit serverseitigen Suchen verwenden
Kann ich hXMLHttpRequest() noch einen Parameter mitgeben, der es mir erlaubt einen solchen Bereich zu definieren? Theoretisch wird auch reichen: Lese von Zeile 5 bis 15 oder so, also nicht Bereich durch HTML Tags definieren, sondern durch Zeilen...
Nein, das ist nicht möglich.
Du kannst allerdings Ausschnitte der Ressource anfordern, z.B. die ersten x Bytes. In gewissen Fällen, meist bei »statischen« Dokumenten, liefert der Server dann den jeweiligen Ausschnitt.
request.setRequestHeader("Range", "bytes=0-199");
»Gebe mir die ersten 200 Bytes der Ressource.«
Firefox zumindest kann das.Mit Opera 8 habe ich hinsichtlich XMLHttpRequest noch nicht herumprobiert. Konntest du denn in Erfahrung bringen, welche Zeile ihn genau zum Absturz bringt?
Mathias
-
Hallo Mathias,
Deshalb würde ich spontan sagen, dass die Idee einer clientseitigen Suche in serverseitigen Dokumenten ... Unsinn ist.
Es ist kein serverseitiges Dokument - zumindest steckt keine serverseitige Scriptsprache dahinter.
In gewissen Fällen, meist bei »statischen« Dokumenten, liefert der Server dann den jeweiligen Ausschnitt.
Da es ein statisches Dokument ist, werde ich das mal antesten - hört sich zumindest gut an....
Mit Opera 8 habe ich hinsichtlich XMLHttpRequest noch nicht herumprobiert.
Er kann es ja offline und auch beim einlesen der CSV Datei für meinen Ligamanger macht er es korrekt, nur das wiederholte einlesen (in einer Schleife) scheint Probleme zu machen.
Konntest du denn in Erfahrung bringen, welche Zeile ihn genau zum Absturz bringt?
Sicher, wenn Du mir sagst, wie ich das machen soll?
"Opera Internet Browser hat ein Problem festgestellt und muss beendet werden. - Fals Sie Ihre Arbeit noch nicht gespeichert hatten, können Daten möglw. verloren gegangen sein. Für weitere Informationen zu diesem Fehler, klicken Sie hier"
Es folgen zwei Button "Debug" (öffnet Delphi - als wenn ich da was sehen könnte *fg*) und "Schließen"Wenn ich "klicken sie hier" auswähle kommt: "
AppName: opera.exe AppVer: 8.0.7561.0 ModName: opera.dll
ModVer: 8.0.7561.0 Offset: 0012c80d"
Was ich mit einem weiteren click noch detailierter sehen kann...Des weiteren wird eine Fehlerdatei (XML) im TMP Ordner angelegt - möchtest Du den Inahlt sehen?
Mit freundlichem Gruß
Micha -
Hallo Mathias,
request.setRequestHeader("Range", "bytes=0-199");
»Gebe mir die ersten 200 Bytes der Ressource.«
Firefox zumindest kann das.JA? hmm...
So habe ich es eingesetzt:request.open("GET", sites2search[i][1], false); request.setRequestHeader("Range", "bytes=0-30"); alert (request.setRequestHeader("Range", "bytes=0-30")); request.send(null);Dabei liefert mir meine alertBox "undefined"
Wenn ich mir request.responseText ausgeben lasse, erhalte ich darüberhinaus auch den gesamten Inhalt der Datei und nicht die ersten 31 byte (Zeichen)...Mit freundlichem Gruß
Micha -
Hallo,
Du kannst allerdings Ausschnitte der Ressource anfordern, z.B. die ersten x Bytes. In gewissen Fällen, meist bei »statischen« Dokumenten, liefert der Server dann den jeweiligen Ausschnitt.
request.setRequestHeader("Range", "bytes=0-199");
»Gebe mir die ersten 200 Bytes der Ressource.«
Firefox zumindest kann das.Das verstehe ich jetzt nicht.
Sowohl IE als auch Mozilla unterstützen bei XMLHTTPRequest.setRequestHeader nur zwei Parameters: header und value (beide Strings).
Was meinst du also damit, dass Firefox "es kann"?Grüße
Thomas-
Hallo,
request.setRequestHeader("Range", "bytes=0-199");
»Gebe mir die ersten 200 Bytes der Ressource.«
Firefox zumindest kann das.Das verstehe ich jetzt nicht.
Sowohl IE als auch Mozilla unterstützen bei XMLHTTPRequest.setRequestHeader nur zwei Parameters: header und value (beide Strings).Ja, das habe ich nicht bezweifelt. Obiges Beispiel nutzt das genau so.
Was meinst du also damit, dass Firefox "es kann"?
Er sendet auch tatsächlich diesen Header bei der Anfrage mit und in responseText sind auch tatsächlich nur die angefragten 200 Bytes enthalten (wenn der Server korrekt mitspielt).
Mathias
-
Hallo Mathias,
Er sendet auch tatsächlich diesen Header bei der Anfrage mit und in responseText sind auch tatsächlich nur die angefragten 200 Bytes enthalten (wenn der Server korrekt mitspielt).
Und wie? ich habe es so proboiert (mit FF)
request.open("GET", sites2search[i][1], false);
request.setRequestHeader("Range", "bytes=0-30");
alert (request.setRequestHeader("Range", "bytes=0-30"));
request.send(null);Die AlertBox liefert mir, das es nicht definiert ist - lokal getestet.
Mit freundlichem Gruß
Micha-
Hallo,
alert (request.setRequestHeader("Range", "bytes=0-30"));
Die AlertBox liefert mir, das es nicht definiert ist - lokal getestet.
Beim Zugriff auf lokale Dateien wird HTTP bekanntlich nicht verwendet, also ist das Festlegen von HTTP-Headern für die GET-Anfrage logischerweise nicht möglich. Daher klappt das lokal per definitionem nicht.
Mathias
-
Hallo Mathias,
Beim Zugriff auf lokale Dateien wird HTTP bekanntlich nicht verwendet, also ist das Festlegen von HTTP-Headern für die GET-Anfrage logischerweise nicht möglich. Daher klappt das lokal per definitionem nicht.
Genau das ist der Denkfehler den ich hatte. Wenn ich es hochlade, funktioniert es so, wie Du es beschrieben hast!
Opera kanns jedoch nicht, aber das hattes Du ja bereits von Anfang an zu bedenken gegeben...
Danke schön!
Mit freundlichem Gruß
Micha
-
-
Hallo,
Und wie? ich habe es so proboiert (mit FF)
request.open("GET", sites2search[i][1], false);
request.setRequestHeader("Range", "bytes=0-30");
alert (request.setRequestHeader("Range", "bytes=0-30"));
request.send(null);Die AlertBox liefert mir, das es nicht definiert ist - lokal getestet.
Wenn du von der Festplatte von einer Datei aus auf Internet zugreifst brauchst du in Mozilla ein:
netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead")Ich habe einen Test gemacht (@Mathias, in der Tat funktioniert das). Der alert() gibt erstmal alle HTTP-Antwort-Header aus, dann geben ich aus dem XML-Datei den gefragten Teil aus (absichtlich als responseTExt und nciht als ResponseXML): http://www.meta-text.net/test/xmlhttprequest.html
Das XML findest du unter http://www.meta-text.net/test/xmlhttprequest.xmlGrüße
Thomas-
ehm...
Wenn du von der Festplatte von einer Datei aus auf Internet zugreifst brauchst du in Mozilla ein:
netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead")ich meinte ein:
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");Thomas
-
Hallo,
Wenn du von der Festplatte von einer Datei aus auf Internet zugreifst brauchst du in Mozilla ein:
Nein, will ich nicht. Ich greife jeweils auf lokale Daten zu.
Es scheint aaber nur bei XML Dateien zu funktionieren oder hast Du mal eine HTML Datei versucht?Mit freundlichem Gruß
Micha-
Hallo,
Wenn du von der Festplatte von einer Datei aus auf Internet zugreifst brauchst du in Mozilla ein:
Nein, will ich nicht. Ich greife jeweils auf lokale Daten zu.
Wie Mathias sagte: lokal von Datei zu Datei gibt es keinen Server.
Es scheint aaber nur bei XML Dateien zu funktionieren oder hast Du mal eine HTML Datei versucht?
Ja: http://www.meta-text.net/test/xmlhttprequest2.html
Grüße
Thomas-
Hallo,
Nein, will ich nicht. Ich greife jeweils auf lokale Daten zu.
Wie Mathias sagte: lokal von Datei zu Datei gibt es keinen Server.
Jo, hatte ich zu spät gelesen. Geht in der Tat - Danke! ;-))
Mit freundlichem Gruß
Micha
-
-
-
-
-
-
-
-