javascript search() arbeitet nicht richtig mit Punkt?

[Henry]

Hallo,

+++++ Nachtrag. Mit indexOf gehts. Bleibt dennoch die Frage, warum search da so seltsam reagiert.

+++++

wenn search() nichts findet ist das Ergebnis -1.

function myFunction() {
var str = "Example Test bla! bla bla"; 
if(str.search("est") ) {alert('est ist vorhanden');}// funktioniert
if(str.search("xxest") <0 ){alert('xxest nicht vorhanden');}// funktioniert
if(str.search("!")){alert('! ist vorhanden');} // funktioniert
if(str.search(".") < 0){alert('Punkt ist nicht vorhanden');} // funktioniert nicht
alert(str.search('.')); // Ausgabe 0
}

Ausser beim Punkt. Da ist das Ergebnis, egal ob vorhanden oder nicht, immer 0. Ich vermute mal das hängt damit zusammen, dass auch regex erlaubt ist oder ein Bug? Wie soll ich denn sonst prüfen ob Punkt da drin ist?

Gruss
Henry

[dedlfix]

Tach!

Ausser beim Punkt. Da ist das Ergebnis, egal ob vorhanden oder nicht, immer 0. Ich vermute mal das hängt damit zusammen, dass auch regex erlaubt ist oder ein Bug?

Und nun? Hast du deine Vermutung mit Hilfe der Dokumentation geprüft? Die Funktion arbeitet jedenfalls in dem Punkt wie beschrieben.

Wie soll ich denn sonst prüfen ob Punkt da drin ist?

Korrekt maskieren.

dedlfix.

[encoder]

(zu spät... dedlfix war schneller)

Ich vermute mal das hängt damit zusammen, dass auch regex erlaubt ist oder ein Bug?

Mit Hilfe einer Vermutungsbestätigungsmaschine (aka Suchmaschine) konnte ich gerade ermitteln dass tatsächlich regex erlaubt sind 😀

Wie soll ich denn sonst prüfen ob Punkt da drin ist?

Indem du den Punkt regex-technisch maskierst. Habs gerade versucht, man braucht dazu zwei Backslashs.
Für eine nicht-regex Suche dürfte indexOf gedacht sein.

[Henry]

Hallo encoder,

Mit Hilfe einer Vermutungsbestätigungsmaschine (aka Suchmaschine) konnte ich gerade ermitteln dass tatsächlich regex erlaubt sind 😀

bin noch nicht sicher ob das jetzt ironisch gemeint ist oder du das tatsächlich gesucht hast. Dass regex erlaubt sind wusste ich natürlich, nur eben nicht ob diese Auswirkung passiert, wenn gar kein regex-schema vorliegt.

Die Suchmaschinen haben so ziemlich gar nichts gebracht zu "javascript punkt search() problem" oder "javascript find dot in string search()" usw…

Wie soll ich denn sonst prüfen ob Punkt da drin ist? Indem du den Punkt regex-technisch maskierst. Habs gerade versucht, man braucht dazu zwei Backslashs.

2 Backslashes, ok da muss man erst mal drauf kommen, danke.

Für eine nicht-regex Suche dürfte indexOf gedacht sein.

Dann habe ich mich ja richtig entschieden, danke.

Gruss
Henry

[dedlfix]

Tach!

Wie soll ich denn sonst prüfen ob Punkt da drin ist? Indem du den Punkt regex-technisch maskierst. Habs gerade versucht, man braucht dazu zwei Backslashs.

2 Backslashes, ok da muss man erst mal drauf kommen, danke.

Das trifft nur zu, wenn du ein String-Literal übergibst. Dann geht zuerst ein Backslash "verloren", weil der allgemeine Syntaxparser den Backslash als Escape-Zeichen hat. Vergleiche console.log('\.'). In der gleichen Situation ist man, wenn man eine Variable aus einem String-Literal erstellt, und die dann übergibt. Der doppelte Backslash sorgt dafür, dass im String selbst ein einzelner Backslash ankommt. Und dieser String wird dann dem RegExp-Objekt übergeben, das den Backslash dann gemäß seiner Regeln auswerten kann.

x.search('\\.')
x.search('\\\\')

Eine Alternative sind Template-Strings

x.search(`\.`)
x.search(`\\`)

Man kann .search() auch ein RegExp-Literal übergeben. Das wird dann direkt geparst ohne den Umweg über einen String. In dem Fall muss man auch keine zusätzlichen für den String notwendigen Maskierungen hinzufügen. Da aber auch hier der Backslash ein Maskier-Zeichen ist, muss er, wenn er literal gemeint ist, auch doppelt notiert werden.

x.search(/\./)
x.search(/\\/)

All das braucht man aber nicht, wenn man gar keine Regular Expressions suchen möchte, denn dafür gibt es:

Für eine nicht-regex Suche dürfte indexOf gedacht sein. Dann habe ich mich ja richtig entschieden, danke.

includes() wäre noch besser, weil das gleich ein boolesches Ergebnis bringt und nicht erst noch die Fundstellenposition ausgewertet werden muss.

dedlfix.

[Felix Riesterer]

Lieber dedlfix,

includes() wäre noch besser, weil das gleich ein boolesches Ergebnis bringt und nicht erst noch die Fundstellenposition ausgewertet werden muss.

ich habe das dann mal eben im Wiki ergänzt.

Liebe Grüße

Felix Riesterer

[encoder]

bin noch nicht sicher ob das jetzt ironisch gemeint ist oder du das tatsächlich gesucht hast.

Deine Formulierung klang für mich als wäre es nur eine Vermutung dass search regex erlaubt und das lässt sich ja rausfinden. Da ich schon länger kein Javascript mehr mache, hab ich das tatsächlich gesucht.
Dass ein Backslash escaped werden muss war mir noch bewusst, deswegen wollte ich ausprobieren ob ich das noch hinkriege 😀

[Henry]

Hallo,

die Frage wurde ja schon beantwortet, danke. In dem Zusammenhang mal was anderes.

Hier im wiki steht:

window.alert-Meldungen unterbrechen den Programmablauf. Manchmal ist dies gewünscht; eine mehrfache Verwendung belastet jedoch den Browser und sollte daher vermieden werden.

Daher wird console.log empfohlen.

Ist das wirklich so? Weil, meine Erfahrung ist komplett andersrum, dass nämlich gerade die Entwicklertools F12 gehörig am System rütteln. Bei alert aber noch nie erlebt.

Gruss
Henry

[Rolf B]

Hallo Henry,

alert ist ein modaler Dialog, und der Browser hält so lange an. Was nachteilig ist, die Seite steht dann still. Falls derweil Events ankommen, werden sie gequeued.

Es belastet auch den User, der ständig Meldungen wegklicken muss und nicht mehr nachgucken kann, was 3 Meldungen zuvor kam.

Um den Programmablauf zu tracen ist console.log besser.

Und dass die Developer-Tools das System stressen, ist logisch. Es ist halt ein Debugger, der arbeitet nicht für umme.

Rolf

[dedlfix]

Tach!

Um den Programmablauf zu tracen ist console.log besser.

Vor allem bietet die Konsole die Möglichkeit, komplexe Dinge (Objekt, Array) komfortabel zu untersuchen. Ein alert() erzeugt daraus eine meistens unbrauchbare Stringrepräsentation.

Und dass die Developer-Tools das System stressen, ist logisch. Es ist halt ein Debugger, der arbeitet nicht für umme.

Eigentlich ist die Frage müßig, denn Fehlermeldungen auf der Konsole sind etwas für Entwickler. Ob bei denen der Rechner brummt, ist nicht weiter relevant. Das fertige Produkt ist - im Idealfall - so weit ausgereift, dass weder Konsolen- noch Alert-Nachrichten ausgegeben werden.

dedlfix.

[JürgenB]

Hallo,

Um den Programmablauf zu tracen ist console.log besser.

Vor allem bietet die Konsole die Möglichkeit, komplexe Dinge (Objekt, Array) komfortabel zu untersuchen. Ein alert() erzeugt daraus eine meistens unbrauchbare Stringrepräsentation.

dabei muss man aber bedenken, dass man bei Objektausgaben nicht den Inhalt zum Zeitpunkt der Ausgabe sieht, sondern zum Zeitpunkt des Betrachtens.

Gruß
Jürgen

[Matthias Apsel]

Hallo JürgenB,

dabei muss man aber bedenken, dass man bei Objektausgaben nicht den Inhalt zum Zeitpunkt der Ausgabe sieht, sondern zum Zeitpunkt des Betrachtens.

Zumindest dann, wenn man sich in der Konsole durch die Struktur des Objekts klickt.

Bis demnächst
Matthias

[Rolf B]

Hallo Matthias,

stimmt wohl. D.h. für eine konservierte Ansicht braucht man eine toString-Methode auf dem Objekt, die die Properties auflöst. Ggf. rekursiv. Oder eine var_dump Methode analog zu PHP…

Das wär eine Fleißaufgabe für's Wiki, wenn es dort nicht schon so etwas gibt.

Rolf

[dedlfix]

Tach!

stimmt wohl. D.h. für eine konservierte Ansicht braucht man eine toString-Methode auf dem Objekt, die die Properties auflöst. Ggf. rekursiv. Oder eine var_dump Methode analog zu PHP…

Zur Not: console.log(JSON.stringify(ding))

dedlfix.

[Christian Kruse]

Hallo dedlfix,

ich nutze für mehr Komfort immer das hier:

console.log(JSON.parse(JSON.stringify(ding))

Das macht eine deep copy, weshalb sich der Wert nicht mehr verändert.

Freundliche Grüße,
Christian Kruse

[JürgenB]

Hallo,

eine Option wäre JSON.stringify

a = {a:"a", b:"b"}
Object { a: "a", b: "b" }

JSON.stringify(a);
"{\"a\":\"a\",\"b\":\"b\"}"

Gruß
Jürgen

[Felix Riesterer]

Lieber JürgenB,

Object { a: "a", b: "b" }

Syntax error in ... ;-)

Liebe Grüße

Felix Riesterer

[JürgenB]

Hallo Felix,

Object { a: "a", b: "b" }

Syntax error in ... ;-)

???. Das ist der Output der Console.

Gruß
Jürgen

[Rolf B]

Hallo Ingrid,

da fällt mir gerade ein 😉, dass JSON.stringify den Job schon tut. Aber nur partiell.

Ein HTML Element wie button wird von stringify als {} aufbereitet, weil die Attribute nicht enumerable sind. Da muss man sich schon mit getOwnPropertyNames/getOwnPropertySymbols über die Prototypenkette hangeln.

Rolf

[dedlfix]

Tach!

dabei muss man aber bedenken, dass man bei Objektausgaben nicht den Inhalt zum Zeitpunkt der Ausgabe sieht, sondern zum Zeitpunkt des Betrachtens.

Jein. Vom Objekt wird anscheinend eine shallow copy erzeugt, das heißt, es selbst und seine Eigenschaften bleiben als Kopie erhalten. Aber nicht die referenzierten Objekte. Die werden aber/erst bei Erstbetrachtung (shallow) kopiert. Dann bleiben sie aber stabil.

dedlfix.

[JürgenB]

Hallo,

dabei muss man aber bedenken, dass man bei Objektausgaben nicht den Inhalt zum Zeitpunkt der Ausgabe sieht, sondern zum Zeitpunkt des Betrachtens.

Jein. Vom Objekt wird anscheinend eine shallow copy erzeugt, das heißt, es selbst und seine Eigenschaften bleiben als Kopie erhalten. Aber nicht die referenzierten Objekte. Die werden aber/erst bei Erstbetrachtung (shallow) kopiert. Dann bleiben sie aber stabil.

wenn man aber keine Breakpoints eingebaut hat und nur die Entwicklung des Objekts am Ende der Laufzeit nachvollziehen möchte, geht das schief. Ich habe da recht viel Zeit verplempert, bis ich das gemerkt habe: „Warum, zum Teufel, verändert sich das &%@#$! Objekt nicht?“

Gruß
Jürgen

[Der Martin]

Hallo Rolf,

alert ist ein modaler Dialog, und der Browser hält so lange an. Was nachteilig ist, die Seite steht dann still. Falls derweil Events ankommen, werden sie gequeued.

Es belastet auch den User, der ständig Meldungen wegklicken muss und nicht mehr nachgucken kann, was 3 Meldungen zuvor kam.

Um den Programmablauf zu tracen ist console.log besser.

Und dass die Developer-Tools das System stressen, ist logisch. Es ist halt ein Debugger, der arbeitet nicht für umme.

das ist alles richtig und logisch, und trotzdem darf man konstatieren:
Die Aussage, alert() belaste den Browser, ist falsch und irreführend.

Live long and pros healthy,
 Martin

[Matthias Scharwies]

Servus!

Hallo Rolf,

alert ist ein modaler Dialog, und der Browser hält so lange an. Was nachteilig ist, die Seite steht dann still. Falls derweil Events ankommen, werden sie gequeued.

Es belastet auch den User, der ständig Meldungen wegklicken muss und nicht mehr nachgucken kann, was 3 Meldungen zuvor kam.

Um den Programmablauf zu tracen ist console.log besser.

Und dass die Developer-Tools das System stressen, ist logisch. Es ist halt ein Debugger, der arbeitet nicht für umme.

das ist alles richtig und logisch, und trotzdem darf man konstatieren:
Die Aussage, alert() belaste den Browser, ist falsch und irreführend.

@Der Martin KönntesT Du das umformulieren / korrigieren? Vielen Dank im Voraus!

Herzliche Grüße

Matthias Scharwies