Ahem.
 FinnO hat folgendes geschrieben  : |
| Außerdem weiß ich nicht, ob es gewollt ist, dass der Button "Eingabefeld vergrößern" das Eingabefeld auf ca. 3-5km höhe ausdehnen soll. |
Genau genommen sind es 205km... äh Zeilen. Und warum das so ist, ist so ein schöner Anfängerfehler dass ich das hier echt mal ausbreiten muss. Immerhin bin ich der, der immer anderen vorwirft, dass sie dynamische Typisierung nicht verstanden haben wenn sie genau das an PHP kritisieren, da muss ich dann wohl mal diesen "Martok" zusammenfalten, der das hier verbrochen hat
Sehen wir uns das mal an.
JavaScript-Quelltext
1:
2:
3:
4:
5:
6:
7:
| PostEdit.ChangeInlineEditHeight = function (post_id, value)
{
var rows = $("#message"+post_id).attr("rows");
if (rows + value >= 5) {
$("#message"+post_id).attr("rows", rows + value);
}
} |
Na, wer siehts schon?
Die beide Parameter sind Zahlen; jQuery-Funktion
attr() gibt den Wert eines Attributs als String zurück. Beim "Verlängern" ist value=5, beim "Verkürzen" ist value=-5
Der
+-Operator entscheidet anhand des ersten (linken) Typs, ob er Addition oder Verkettung macht. Und was ist das hier? Richtig, String. Also Verkettung.
Kommen wir also vom Standard von 20 Zeilen, steht da:
JavaScript-Quelltext
Und "20" + (5).toString() ist der String "205".
Spannender ist das beim Einkürzen danach:
JavaScript-Quelltext
1:
| if ("205" + (-5) >= 5) { |
Und "20" + (-5).toString() ist der String "205-5".
>= mit Strings wiederum ist der lexikalische Vergleich. Und da ist "205-5" < "5", da "2" < "5". Und deswegen funktioniert das nicht.
Klarer Anwendungsfall für den Failsafe-Cast "Multiplikation", der nämlich im Gegensatz zu parseInt() bei nicht-Strings nicht
NaN erzeugt.
JavaScript-Quelltext
1:
| var rows = 1 * $("#message"+post_id).attr("rows"); |
Und so steht das da jetzt im Testforum auch
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
