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