nicht angemeldet
Moin!
Ja, latürnich. pInput.onchange() führt dazu, daß die zugeordnete Funktion zum Testen des Inputs aufgerufen wird. Sogar mit dem im Funktionsaufruf deklarierten Parametern (in diesem Fall this - zur Übergabe eines Zeigers auf das Element).
Den Ansatz finde ich irgendwie ungewöhnlich. Üblicherweise vermutet man in dem durch den Event "onchange" aufgerufenen Code etwas, was darauf reagiert, dass _eben gerade_ der Inhalt des Formularfeldes verändert wurde.
Dass man genau den gleichen Code nochmal beim Abschicken des Formulars benutzt, und das auch noch funktioniert wie gewünscht, liegt dann wohl eindeutig am aufgerufenen Code. :)
Ich persönlich wäre nicht auf solche seltsamen Ideen gekommen, sondern hätte die onchange aufgerufene TestFkt einfach mit dem passenden Formularelementobjekt aufgerufen - das würde genauso gut funktionieren.
Abgesehen davon hänge ich persönlich ja sehr an den altbekannten Collections für Formulare und Elemente. Die sind bestens erprobt, im DOM-Standard verankert und durchaus performanter ansprechbar, als getElement(s)By*().
Mit null!=pInput.onchange wird lediglich geprüft, ob ein onChange-Handler überhaupt definiert ist. So weit, so gut. Nur mit der Rückgabe des Resultates der aufgerufenen Funktion klappt es leider nicht.
Was ja wiederum bedeutet, dass die Prüfung des Formularfeldes ausfällt, wenn kein Eventhandler definiert ist.
Andererseits kann man statt einer Einheitsfunktion für alle Felder so natürlich jedes Formularfeld mit seiner individuellen Checkfunktion versehen.
Aber trotzdem: Sowas würde ich nicht über das manuelle Abfeuern eines tatsächlich nicht stattgefundenen Events regeln, so nach dem Motto "tun wir mal so, als wäre das Formularfeld geändert worden - was wäre denn dann zu tun?" :)
- Sven Rautenberg
My sssignature, my preciousssss!