nicht angemeldet
Funktion automatisch ausführen ohne onLoad
StruppiGuten Abend Community,
ich bin jez schon die ganze Zeit am überlegen, wie ich eine Javascript-Funktion automatisch aufrufe (also direkt, wenn die Seite mit dem Script geöffnet wird).
Ich hatte diese Frage hier schonmal gestellt und die wurde auch super benatwortet. Leider habe ich die Lösung nach längerer Zeit wieder vergessen und das von mir erstellte Thema habe ich auch nicht wieder gefunden.
Das ganze hatte etwas mit der Funktion setTimeout zu tun, soweit ich mich erinnern kann.
Wäre nett, wenn mir da nochmal jemand helfen kann. Danke =)
-
Grüße,
function bla(){ } bla();MFG
bleicher--
__________________________-
Die Essenz der Egomanie
ie:{ fl:( br:< va:| ls:[ fo:# rl:? n4:? ss:| de:> js:| ch:| sh:( mo:| zu:|-
Grüße,
function bla(){
}
bla();> > MFG > bleicher >\_< wtf ....Danke.-
Funktioniert leider nicht Oo.
<script type="text/javascript" language="javascript"> function setTransparency(){ // Objekt holen strID = "transparent-td-1"; var myObj = (IE)?document.all[strID]:document.getElementByID(strID); if(IE){ intWert = 50; myObj.style.filter = "alpha(opacity="+intWert+")"; } } setTransparency(); </script>Nur nach Klick auf den Button wird die Funktion aufgerufen.
<input type="button" onclick="setTransparency()" value="transparenz" />-
Nur nach Klick auf den Button wird die Funktion aufgerufen.
Wann soll sie denn sonst ausgeführt werden?
<input type="button" onclick="setTransparency()" value="transparenz" />Das Beispiel von bleicher war anders.
Struppi.
-
Wann soll sie denn sonst ausgeführt werden?
Direckt beim Aufruf der Seite und dies ohne <body onload=...
Das Beispiel von bleicher war anders.
Das Beispiel von bleicher funktioniert aber nicht.
-
Hallo Battler,
gucke mal: Wenn Du die Funktion aufrufst, ist doch noch nicht mal <body> vom Browser geparst worden. Wie also soll auf ein Element, das innerhalb vom <body> mit der ID "transparent-td-1" schlummert, überhaupt gefunden werden?
Deiner Bedingung im Ausgang folgend, sollte folgendes zwar arbeiten:
<element id="transparent-td-1"></element> <script type="text/javascript"> setTransparency(); </script>Mir ist aber nicht ersichtlich und auch nicht nachvollziehbar, warum onload nicht benutzt werden soll. Bitte beschreibe die Intension dahinter! Vielleicht gibt es dazu dann auch noch eine Idee, die das ganze allumfassend befriedigt.
Gruß aus Berlin!
eddi--
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!-
Hey eddi,
danke für deine Antwort.gucke mal: Wenn Du die Funktion aufrufst, ist doch noch nicht mal <body> vom Browser geparst worden. Wie also soll auf ein Element, das innerhalb vom <body> mit der ID "transparent-td-1" schlummert, überhaupt gefunden werden?
Deiner Bedingung im Ausgang folgend, sollte folgendes zwar arbeiten:
<element id="transparent-td-1"></element>
<script type="text/javascript">
setTransparency();
</script>> Das was du sagst ist richtig! Das hat Kai345 auch bereits gesagt und ich habe ihm geantwortet (solltest du dir mal anschauen =). > Mir ist aber nicht ersichtlich und auch nicht nachvollziehbar, warum onload nicht benutzt werden soll. Bitte beschreibe die Intension dahinter! Vielleicht gibt es dazu dann auch noch eine Idee, die das ganze allumfassend befriedigt. »» Ich versuch das mal zu erklären: Meine Internetpräsenz ist so aufgebaut, dass verschiedene php-dateien in die index.php geladen werden, die dann die einzelen Bereiche darstellen sollen Diese section sind abhängig von einer GET-Variabel. Diese GET-Variabel änder sich je nachdem, welchen Link man anwählt (z.B. `<a href="index.php?section=media_music">Musik</a>`{:.language-html}) Das ganze ist ziemlich umfangreich gestaltet worden. Hier ein kleiner Auszug: ~~~php <?php // Inhalt der sections.php bei root/php/ $contentdata['media_pictures'] = 'content/media/pictures/index.php'; $contentdata['media_videos'] = 'content/media/videos/index.php'; $contentdata['media_music'] = 'content/media/music/index.php'; $contentdata['media_clients'] = 'content/media/clients/index.php'; $contentdata['media_other'] = 'content/media/other/index.php'; // Inhalt der index.php bei root/ if (isset($_GET['section']) AND isset($contentdata[$_GET['section']])) { include $contentdata[$_GET['section']]; } else { include $contentdata['news']; } ?>Die index-dateien der einzelnen Sektionen enthalten in diesem Falle kein body-tag.
Es geht darum, dass die Funktion nur in einer bestimmten Sectionen meiner Homepage aufgerufen werden soll.
Und da sich der body-tag (an dem man den onload-paramtere anwendet) sich in der index.php befindet, würde die Funktion in der jeder Sektion (sei es News, Gästebuch etc...) aufgerufen werden.
Klar soweit ?Wenn es an dieser Stelle Verbesserungsvorschälge gibt, würde ich mich natürlich auch freuen =)
greez.
b4ttl3m4st3r-
<?php ...Das ist verständlich; okay. Du musst es nicht machen, aber vielleicht mal als kleiner Denkanstoß:
function dl (){ var f=new Array('functionsname1''functionsname2''functionsname3''functionsname4'); for(var i=0;i<f.length;i++) window[f[i]](); }<body onload="dl()">Ich mag's eben gerne elegant. ;)
eddi--
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!-
»»
<?php ...Das ist verständlich; okay. Du musst es nicht machen, aber vielleicht mal als kleiner Denkanstoß:
function dl (){
var f=new Array('functionsname1''functionsname2''functionsname3''functionsname4');
for(var i=0;i<f.length;i++)
windowf[i];
}> `<body onload="dl()">`{:.language-html} > > > Ich mag's eben gerne elegant. ;) > eddi > Ja elegant wär mir auch lieber. Ich versuch ja schon, meinen Code so sauber wie möglih zu halten und würde auf jeden Fall auch Perfektion anstreben xP. Nur leider fehlen mir bei manchen Sachen die nötigen Kenntnisse, um den wohlgewollten 'besseren Code' aufs Papier bzw. auf Adobe's Dreamweaver zu übertragern ;) Dein oben genannter Code sieht sehr interessant aus und stellt eine gute Lösung dar. Um darin allerdings die Vorzüge zu erkennen, müsste ich mich ein bisschen länger mit JavaScript beschäftigen. Ich kann deinen Ansatz nämlich überhaupt nicht mit meinem hier beschriebenen und bereits gelösten Problem in verbindung bringen, da sich hier ja nun wieder alle Funktionen (in diesem Fall 1-4) im body-tag befinden. Danke =) -
function dl (){
var f=new Array('functionsname1''functionsname2''functionsname3''functionsname4');
for(var i=0;i<f.length;i++)
windowf[i];
}> `<body onload="dl()">`{:.language-html} > > Ich mag's eben gerne elegant. ;) OMFG, das ist alles, aber nicht elegant! Jedenfalls nicht in einer funktionalen Sprache wie JavaScript. - Keine Event-Handler-Attribute im HTML. - Keine zentrale Initialisierungsfunktion - Kein zentraler Array mit globalen Funktionsnamen Besser: - Eine [addEvent-Funktion](http://molily.de/js/einbindung.html#addevent-helfer) (oder ein Framework der Wahl) - Diese mehrfach aufrufen immer dort, wo ein Modul notiert wird function bla () {} addEvent(window, "load", bla); Modul = { init: function () {} }; addEvent(window, "load", Modul.init); usw. Die Pflege einer zentralen Funktion fällt dann weg, auch die Funktionsnamen müssen nicht als Strings notiert werden, was den Code wartbarer macht. - Nächster Schritt: [DOMContentLoaded](http://molily.de/js/einbindung.html#domcontentloaded-crossbrowser) statt window.onload (das können alle Frameworks von Haus aus) Mathias -- [JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)-
OMFG, das ist alles, aber nicht elegant! Jedenfalls nicht in einer funktionalen Sprache wie JavaScript.
- Keine Event-Handler-Attribute im HTML.
- Keine zentrale Initialisierungsfunktion
- Kein zentraler Array mit globalen Funktionsnamen
Besser:
- Eine addEvent-Funktion (oder ein Framework der Wahl)
- Diese mehrfach aufrufen immer dort, wo ein Modul notiert wird
function bla () {}
addEvent(window, "load", bla);Modul = {
init: function () {}
};
addEvent(window, "load", Modul.init);[..]
Mathiasnice ! xD
jetzt versteh ich noch weniger.
Trotzden Danke xP -
Hallo Mathias,
OMFG, das ist alles, aber nicht elegant!
was soll das? Ist das etwa nicht die Art von Umgang, die Stefan Münz, als er über das Forum sprach, rügte?
- Keine Event-Handler-Attribute im HTML.
- Keine zentrale Initialisierungsfunktion
- Kein zentraler Array mit globalen Funktionsnamen
Besser:
- Eine addEvent-Funktion (oder ein Framework der Wahl)
- Diese mehrfach aufrufen immer dort, wo ein Modul notiert wird
Hier schriebst Du mir noch etwas von Performence und jetzt soll ich statt onload ein deine addEvent-Funktion nehmen, was dem entsprechenden Beispiel völlig abwegig gar nicht funktionieren wird, weil das Element noch gar nicht im DOM-Baum ist, oder gar ein ganzes Framework dafür verwenden?!
Die Pflege einer zentralen Funktion fällt dann weg, auch die Funktionsnamen müssen nicht als Strings notiert werden, was den Code wartbarer macht.
Es muss lediglich ein "zentrales" Array "gepflegt" werden -u nd nicht eine Umstantsprofessur durch eine über 1kB-großen Workaround für den IE gemacht werden.
Alles in allem, Mathias, gewinne auch ich den Eindruck, dass Du manchmal einfach zu schnell tippst.
Gruß aus Berlin!
eddi--
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!-
Hi,
- Eine addEvent-Funktion (oder ein Framework der Wahl)
- Diese mehrfach aufrufen immer dort, wo ein Modul notiert wird
Hier schriebst Du mir noch etwas von Performence und jetzt soll ich statt onload ein deine addEvent-Funktion nehmen, was dem entsprechenden Beispiel völlig abwegig gar nicht funktionieren wird, weil das Element noch gar nicht im DOM-Baum ist
Mathias benutzt addEvent, um mehrere Funktionen beim Eintreten des load-Ereignesses von window ausführen zu lassen - was soll da bitte im DOM noch gar nicht vorhanden sein?
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Hallo ChrisB,
| > - Eine addEvent-Funktion (oder ein Framework der Wahl)
| > - Diese mehrfach aufrufen immer dort, wo ein Modul notiert wird
|
| Hier schriebst Du mir noch etwas von Performence und jetzt soll ich statt onload ein deine addEvent-Funktion nehmen, was dem entsprechenden Beispiel völlig abwegig gar nicht funktionieren wird, weil das Element noch gar nicht im DOM-Baum istMathias benutzt addEvent, um mehrere Funktionen beim Eintreten des load-Ereignesses von window ausführen zu lassen - was soll da bitte im DOM noch gar nicht vorhanden sein?
Okay, das sehe ich jetzt auch so, beschrieben hat er dies jedoch nicht.
Im Beispiel unter 21.2 addEvent-Helferfunktionen spiegelt sich dies ebensowenig wieder:<p id="beispielabsatz">Klick mich!</p> <script type="text/javascript">~~~javascriptfunction absatzKlick () {
alert("Der Absatz wurde geklickt!");
}
addEvent(document.getElementById("beispielabsatz"), "click", absatzKlick);`</script>`{:.language-html} Auch ist mir nicht ersichtlich, warum ~~~javascript function bla () {} addEvent(window, "load", bla); Modul = { init: function () {} }; addEvent(window, "load", Modul.init);hinter jedem "Modul" eleganter sein soll, als folgendes:
f.push('functionsname');Gruß aus Berlin!
eddi--
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!-
Auch ist mir nicht ersichtlich, warum
function bla () {}
addEvent(window, "load", bla);
Modul = {
init: function () {}
};
addEvent(window, "load", Modul.init);> > hinter jedem "Modul" eleganter sein soll, als folgendes: > > `f.push('functionsname');`{:.language-javascript} Weil es von der Funktionalität her etwas anderes ist und andere Möglichkeiten bietet. Objektnamen gibt man nicht als Strings an, wenn es nicht nötig ist. Wenn man den Namen mal ändern will, wird das automatisierte Refactoring schwierig. Wenn man irgendwann den Code in einer Funktion kapseln will, um ihn mit anderen Scripten zusammenarbeiten zu lassen, dann gibts keine globalen Funktionen mehr. Der Code würde unverändert weiter funktionieren, wenn man nicht window["funktionsname"], sondern mit Funktionsreferenzen gearbeitet hätte. In JavaScript sind i.d.R. nur Objekt-Referenzen interessant, nicht deren globale Namen. Mit Funktionsreferenzen arbeitet man beim Event-Handling eigentlich immer, ob man nun traditionelles Handling, addEventListener, attachEvent oder ein eigenes addEvent benutzt. Warum das Rad neu erfinden, indem man für window.onload plötzlich auf eine Lösung mit Strings mit Namen globaler Funktionen setzt. Das ist viel unflexibler als eine Lösung mit Referenzen. Wenn man seine JavaScripte [organisiert](http://aktuell.de.selfhtml.org/artikel/javascript/organisation/), Object-Literale, OOP oder andere Design Pattern verwendet, dann kann man gar nicht mit dutzenden losen globalen Funktionen arbeiten. Letzteres verleitet einen nur dazu, den globalen Namespace ungeordnet vollzuballern, was man bestenfalls von Anfang an vermeiden sollte. addEvent(window, "load", Modul.init); kann man gar nicht mit Funktionsnamen in einem String umsetzen. Mathias -- [JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)-
Re:
Objektnamen gibt man nicht als Strings an, wenn es nicht nötig ist. Wenn man den Namen mal ändern will, wird das automatisierte Refactoring schwierig. Wenn man irgendwann den Code in einer Funktion kapseln will, um ihn mit anderen Scripten zusammenarbeiten zu lassen, dann gibts keine globalen Funktionen mehr. Der Code würde unverändert weiter funktionieren, wenn man nicht window["funktionsname"], sondern mit Funktionsreferenzen gearbeitet hätte.
Nicht jeder verfährt nach dem Konzept "Objekt ist gut™", da die ja so schön portabel sind, weil eierlegende Wollmilchsäue in der Programmierung von jeher ein graus sein sollten. Dementsprechend gebe ich aus verschiedenen, weiteren Gründen einer Einpassung von Code, also deren problemorientierten und zumeist nicht portablen Routinen, jedenfalls den Vorrang. Alles andere wäre für mich Dreamwave & Co bzw. Overhead.
Aber lass uns nochmals auf ein anderen Einwurf von Dir eingehen:
| | - Keine zentrale Initialisierungsfunktion
Die Nutzung von onload hat eben aus Gründen der Übersichtlichkeit und Wartbarkeit von Code i. V. m. einer zentralen Initialisierungsfunktion große Vorteile. In einer Initialisierungsfunktion kann ich ganz einfach mittels
alert(initial_array)und ähnlichen Hilfsmitteln mir sehr schnell einen Überblick verschaffen. Ich muss auch nicht lange in den Gesamten Scripten und Dokumenten eines Projektes wühlen, um die Initialisierung zu ermitteln. Ich muss nur<body>ausfindig machen und gucke mir an, was im onload steht....Warum das Rad neu erfinden,...
Richtig: <body onload="initial_funktion()">
Kein zusätzlicher workarounds für den IE notwendig, übersichtlich und wartbar.
Das ist viel unflexibler als eine Lösung mit Referenzen. Wenn man seine JavaScripte organisiert, Object-Literale, OOP oder andere Design Pattern verwendet, dann kann man gar nicht mit dutzenden losen globalen Funktionen arbeiten.
Triviale Probleme bedürfen keiner Objekte. Daran scheiden sich hier offensichtlich die Geister. Für das Originalproblem des Threads halte ich addEvent() für eine Alternative, Objekte, wie Du sie jetzt zum Argument instrumentalisierst, berühren das Thema IMHO jedoch gar nicht. Zudem steht immer noch Dein Einwurf bei einem Beispiel, der Performance wegen, dem entgegen, dass man lieber nicht mit Kanonen auf seine Spatzen schießen sollte.
Letzteres verleitet einen nur dazu, den globalen Namespace ungeordnet vollzuballern, was man bestenfalls von Anfang an vermeiden sollte.
Das halte ich für kein diskussionswürdiges Argument, da es nur um einen einzigen Variablennamen geht.
addEvent(window, "load", Modul.init); kann man gar nicht mit Funktionsnamen in einem String umsetzen.
Womit wir wieder bei der Notwendigkeit von Objekten wären...
Mathias, schreib, was Du willst! Ich wäre auch nicht verlegen, gegen jedes Licht, was Du neu wirfst, auch den Schatten daran zu umreisen. Gib einfach bescheid, wenn Du Schwarzweiß in Form von Schach oder Go bevorzugen solltest. ;)
Gruß aus Berlin!
eddi--
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!-
Nicht jeder verfährt nach dem Konzept "Objekt ist gut™"
JavaScript tut es jedenfalls, weil alles ein Objekt ist.
Aber inwiefern ist das ein Einspruch gegenüber meinen Aussagen? Verfährst du nach dem Konzept »Objekt ist schlecht«? Okay, was ist denn schlecht daran?Dementsprechend gebe ich aus verschiedenen, weiteren Gründen einer Einpassung von Code, also deren problemorientierten und zumeist nicht portablen Routinen, jedenfalls den Vorrang.
Inwiefern ist der Ansatz mit Funktionsnamen als Strings problemorientierter? Ich sehe keinen Overhead darin, das eine Schema des Event-Handlings mit Callback-Funktionen durchzuhalten. Das ist so ziemlich das einfachste und weit verbreiteste in JavaScript. Wenn man es einmal gerallt hat, und das muss man, weil eben halb JS darauf aufbaut, dann kann man damit sehr elegante funktionale Problemlösungen finden.
Die Nutzung von onload hat eben aus Gründen der Übersichtlichkeit und Wartbarkeit von Code i. V. m. einer zentralen Initialisierungsfunktion große Vorteile.
Ich will gar nicht sagen, dass das in jeden Fall Unsinn ist, und ja, es kommt auf den Anwendungsfall an. Ich verwende selbst oft zentrale Initialisungsfunktionen der Art:
window.onload = function () {
Dies.init();
Das.init();
Jenes.init();
};-- wenn es denn zur Lösung des Problems ausreicht. Das stößt natürlich unglaublich schnell an seine Grenzen, wie man hier im Forum bei unzählig vielen JavaScript-Fragen sehen kann. Die Nachteile davon sind bekannt. Warum man das nicht im HTML unterbringt, ist auch hinreichend diskutiert. Ich habe schon öfters darüber geschrieben und kann nur auf meine zahlreichen Artikel verweisen.
Wenn man sich dieser Einschränkungen bewusst ist, ja, dann kann man obiges problemlos einsetzen. Wenn man aber ohnehin schon dazu übergeht, sich eine Helfer-Funktion à la »addLoadEvent« zu basteln, dann sollte man m.E. auch einen Schritt weiter gehen.
Obiges Modell halte ich nicht für per se wartbarer als das Notieren eines addEvents beim Modul selbst. Das ist zum Teil schlicht Gewohnheit. Manche wollen Zusammenhängendes nahe beieinander, also auch die Registrierung der Init-Funktionen. Bei wenigen Scripten ist das auch problemlos zentral zu verwalten. Sobald man aber mehrere Scripte aus verschiedenen Quellen hat, die auf einer Site auch nicht alle notwendig gleichzeitig eingebunden und initialisiert werden, ist eine Modularisierung angebracht.
Das geht meiner Erfahrung nach recht schnell - Grund genug für mich, Anfängern dazu zu raten, sich bereits recht früh in die fortgeschrittenen Methoden einzuarbeiten, weil sie früher oder später in die hinreichend bekannten Fettnäpfchen treten werden. Dafür, dass die meisten Leute heutzutage wohl JavaScript mit jQuery und Co. lernen, ist dieser Ansatz noch äußerst bodenständig. Wenn du dir mal meine JS-Doku anschaust, wirst du sicher erkennen, dass ich keinesfalls grundlos überkomplexe Lösungen empfehle. Ich verschweige aber auch nicht die Nachteile von einfachen und zeige flexiblere auf.
In einer Initialisierungsfunktion kann ich ganz einfach mittels
alert(initial_array)und ähnlichen Hilfsmitteln mir sehr schnell einen Überblick verschaffen.Die Modulverwaltung meines Forumsscriptes funktioniert ähnlich - wenn auch vornehmlich aus anderen Gründen (es gibt verschiedene Seiten und ein Modul muss nicht notwendig bei allen Seiten initialisiert werden).
Richtig: <body onload="initial_funktion()">
Kein zusätzlicher workarounds für den IE notwendig, übersichtlich und wartbar.
Nein, es ist nicht gut wartbar, JS-Code mit den Dokumenten zu verschmelzen. Das Konzept der klaren Trennung von HTML, CSS und JavaScript (Semantisches Markup + CSS-Layout + Unobtrusive JavaScript) ist einfach die größte Errungenschaft im Webdesign. Da sich in einem ausgelagerten JS äquivalent window.onload = initial_funktion; notieren lässt (bzw. weitaus flexiblere Methoden existieren), besteht keine Notwendigkeit, das fest in alle Dokumente zu schweißen - und alle anpassen zu müssen, wenn sich das einmal ändert.
Triviale Probleme bedürfen keiner Objekte. Daran scheiden sich hier offensichtlich die Geister.
Ich empfehle hier eigentlich fast immer Low-Level-Lösungen, wenn es denn um triviale Probleme geht.
Vielleicht hast du das missverstanden, ich habe auf dein Posting ursprünglich nicht geantwortet, um eine alternative, auf den konkreten Fall des Fragestellers optimal zugeschnittene Lösung zu präsentieren. Vielmehr ging es mir um einen Ausblick auf - nun, eben »elegante« Lösungen, die sich an bestehenden funktionalen Programmiertechniken orientieren, in den restlichen JS-Gebrauch enschmiegen (addEvent kann man immer gebrauchen) und eine stärkere Flexibilität aufweisen. Darauf hinzuweisen halte ich für nötig angesichts dessen, dass eben nicht jeder Teilnehmer hier auf demselben Wissenstand ist.
Für das Originalproblem des Threads halte ich addEvent() für eine Alternative, Objekte, wie Du sie jetzt zum Argument instrumentalisierst, berühren das Thema IMHO jedoch gar nicht.
Wenn ich schon so weit bin, dass ich mehrere Initialisierungsfunktionen habe, dann hängen da meistens jeweils mehrere Funktionen und Variablen dran - Grund genug, diese in Objekten zu gruppieren (und sie bestenfalls konfigurierbar und wiederverwendbar zu machen). Das ist schlicht *die* JavaScript-typische Umsetzung - im Gegensatz zu vielen globalen Objekten mit Namespace-Präfixen im Namen.
Zudem steht immer noch Dein Einwurf bei einem Beispiel, der Performance wegen, dem entgegen, dass man lieber nicht mit Kanonen auf seine Spatzen schießen sollte.
Ich wüsste nicht, was an der Gruppierung von zusammenhängenden Funktionen und Variablen an einem Objekt-Literal unangemessen ist. Im Gegenteil, es verbessert die Übersichtlichkeit im Code enorm. Was hast du dagegen einzuwenden? Was ist daran komplex oder verschlechtert die Performance? Was bevorzugst du?
Letzteres verleitet einen nur dazu, den globalen Namespace ungeordnet vollzuballern, was man bestenfalls von Anfang an vermeiden sollte.
Das halte ich für kein diskussionswürdiges Argument, da es nur um einen einzigen Variablennamen geht.
Ich habe nicht von »f« aus deinem Beispiel gesprochen, sondern von den vielen globalen Funktion samt »Anhängen«.
Mathias, schreib, was Du willst!
Den Eindruck, gegen eine Wand zu reden, habe ich tatsächlich.
Mathias
-
-
-
Mathias benutzt addEvent, um mehrere Funktionen beim Eintreten des load-Ereignesses von window ausführen zu lassen - was soll da bitte im DOM noch gar nicht vorhanden sein?
Okay, das sehe ich jetzt auch so, beschrieben hat er dies jedoch nicht.addEvent ist eine Allround-Funktion für jegliches Event-Handling. »window.onload« ist auch nur Event-Handling, also kann man addEvent (mit addEventListener/attachEvent) auch dafür verwenden.
Im Beispiel unter 21.2 addEvent-Helferfunktionen spiegelt sich dies ebensowenig wieder:
<p id="beispielabsatz">Klick mich!</p>
<script type="text/javascript">
> ~~~javascript function absatzKlick () { > alert("Der Absatz wurde geklickt!"); > } > addEvent(document.getElementById("beispielabsatz"), "click", absatzKlick);</script>Korrekt, das Beispiel demonstriert nicht das Registrieren von Handlern für den dokumentweiten load-Event. Es demonstriert den Einsatz beim Event-Handling bei DOM-Elementen. In dem Fall ist der Zugriff auf das Element natürlich vonnöten. Weil es in dem Beispiel bloß darum geht, den Aufruf von addEvent zu illustrieren, habe ich die drei Teile an der Stelle weggelassen und mit einem Script gearbeitet, was bereits durch seine Lage im Dokument Zugriff auf das zuvorliegende Element hat.
Mit addEvent sähen diese (mit mehreren globalen Funktionen) so aus:
// 1. Teil addEvent(window, "load", absatzKlickInit); // 2. Teil function absatzKlickInit () { addEvent(document.getElementById("beispielabsatz"), "click", absatzKlick); } // 3. Teil function absatzKlick () { alert("Der Absatz wurde geklickt!"); }Da ich das für nicht optimal halte und den Einsatz von DOMContentLoaded empfehle, habe ich (noch) kein entsprechendes Beispiel aufgenommen.
Mathias
-
Re:
| ~~~html
<p id="beispielabsatz">Klick mich!</p>
| <script type="text/javascript">
> | ~~~javascript function absatzKlick () { > | alert("Der Absatz wurde geklickt!"); > | } > | addEvent(document.getElementById("beispielabsatz"), "click", absatzKlick);|
</script>Genau darum dreht sich aber die Debatte - ja das Debakel - auf ein unübersichtlich, unnütiges und schwer wartbares
<script>zu verzichten. Für mich ist dann Ende mit Debatte. Die Standpunkte sind deutlich und gegensätzlich umrissen.Gruß aus Berlin!
eddi--
Wer mit Kanonen auf Spatzen schießt, mag zwar immernoch Augen für die Tauben auf dem Dach haben, aber keine Hand zum reichen.
-
-
-
OMFG, das ist alles, aber nicht elegant!
was soll das?
Steht doch da: Dein Code ist nicht elegant. Das mag ich harsch formuliert haben, gebe ich gerne zu. Aber dass du zubeißt, offenbar ohne die Aussagen und Argumente meines Postings näher betrachtet zu haben, ist auch nicht gerade die feine englische.
Es muss lediglich ein "zentrales" Array "gepflegt" werden -u nd nicht eine Umstantsprofessur durch eine über 1kB-großen Workaround für den IE gemacht werden.
Ich glaube, da missverstehst du etwas. DOMContentLoaded ist ein anderer Ansatz als window.onload. Er ist kein »Workaround für den IE«. Der IE-spezifische Teil ist 19 Zeilen lang. Was es damit auf sich hat, habe ich versucht, in meiner JavaScript-Doku zu beschreiben.
Mathias
-
- Nächster Schritt: DOMContentLoaded statt window.onload (das können alle Frameworks von Haus aus)
Der Link war vielleicht zu spezifisch. Um DOMContentLoaded zu verstehen, sollte man zumindest vom Anfang des Unterkapitels an lesen.
Das Ausgangsproblem, bei dem DOMContentLoaded ansetzt, hat Struppi ganz gut beschrieben: window.onload wartet auf das Laden aller externen Ressourcen, für das sog. DOM-Scripting, also das Registrieren von Event-Handlern bei Elementen im DOM, braucht man aber lediglich Zugriff auf den DOM-Baum. Dieser Event tritt eben schon viel früher ein.
Mathias
-
-
-
Und da sich der body-tag (an dem man den onload-paramtere anwendet) sich in der index.php befindet, würde die Funktion in der jeder Sektion (sei es News, Gästebuch etc...) aufgerufen werden.
Klar soweit ?Wenn es an dieser Stelle Verbesserungsvorschälge gibt, würde ich mich natürlich auch freuen =)
Du musst onload nicht im body Tag aufrufen, du kannst diesen Aufruf auch in einem Skriptblock anstossen.
<script type="text/javascript"> window.onload = function() { .... } </script>Aber in deinem Fall ist es vermutlich sinvoller den Aufruf einfach im HTML Code hinter das Elemente zu platzieren.
Struppi.
-
-
Mir ist aber nicht ersichtlich und auch nicht nachvollziehbar, warum onload nicht benutzt werden soll.
onload feuert erst, wenn alles geladen wurde. Bilder, alle externen Dateien und das kann u.U. lange dauern, daher ist es keine schlechte Idee ein Skript vor dem onload zu starten.
Struppi.
-
-
-
-
[latex]Mae govannen![/latex]
Funktioniert leider nicht Oo.
Und die Fehlerkonsole meint dazu?
<script type="text/javascript" language="javascript">
function setTransparency(){
// Objekt holen
strID = "transparent-td-1";
var myObj = (IE)?document.all[strID]:document.getElementByID(strID);
if(IE){
intWert = 50;
myObj.style.filter = "alpha(opacity="+intWert+")";
}
}
setTransparency();
</script>> > Nur nach Klick auf den Button wird die Funktion aufgerufen. Die Funktion dürfte hier schon direkt aufgerufen werden [und wiederholt beim Klick], allerdings vermute ich, daß beim (ersten) Direktaufruf das Element mit id="strID" noch nicht verfügbar ist und es deshalb so aussieht, als wäre sie nicht aufgerufen worden. Setze diesen Block im HTML entweder hinter das entsprechende Element oder rufe die Funktion erst bei onload auf. und in der Zeile var myObj = ..... kannst du alles hinter dem Gleichheitzeichen bis einschließlich dem Doppelpunkt ersatzlos löschen, es sei denn, du willst IE4!! beachten. Und die Methode document.getElementByID gibt es im Gegensatz zu document.getElementById nicht. Cü, Kai -- „It's 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it's dark, and we're wearing sunglasses“. „Hit it!“ [Selfzeugs](http://kaichen.in/selfhtml/) SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Danke für die schnelle Antwort !
Funktioniert ! =)Und die Fehlerkonsole meint dazu?
Fehler: 'style' ist Null oder kein Objekt
Code: 0Die Funktion dürfte hier schon direkt aufgerufen werden [und wiederholt beim Klick], allerdings vermute ich, daß beim (ersten) Direktaufruf das Element mit id="strID" noch nicht verfügbar ist und es deshalb so aussieht, als wäre sie nicht aufgerufen worden. Setze diesen Block im HTML entweder hinter das entsprechende Element oder rufe die Funktion erst bei onload auf.
Vollkommen richtig, was du sagst.
Ich habe den script-teil hinter das Object mit der ID gestellt und nun läuft es. Das hätte ich vielleicht auch mal in meinen ersten Beitrag mit rein schreiben sollen - sorry. Auf sowas wäre ich nie gekommen.
Mit onload wollte ich hier ja nicht arbeiten (siehe Thementitel), da man diesen Operator nur im body-tag nutzen kann (soweit ich das verstanden habe).und in der Zeile var myObj = ..... kannst du alles hinter dem Gleichheitzeichen bis einschließlich dem Doppelpunkt ersatzlos löschen, es sei denn, du willst IE4!! beachten. Und die Methode document.getElementByID gibt es im Gegensatz zu document.getElementById nicht.
Im Grunde geht es hier eben darum, die älteren Browser anzusprechen.
Die Version 6 (und abwärts) des Internet Explorers stellen keine (halb-)transparenten Bilder dar.
Für Firefox verwende ich nun ein halb-transparentes Hintergrundbild (normales stylesheet) und für IEv6 wird das normale Bild geladen und dies dann mittels Javascript transparent gemacht (stylesheet speziell für IEv6 & die oben genannte JSFunktion).
Ob dies der beste Weg ist kann ich beim besten Willen nicht sagen, aber ich bin erstmal froh, dass es klappt.Herzlichen Dank ^_^
-
Die Version 6 (und abwärts) des Internet Explorers stellen keine (halb-)transparenten Bilder dar.
Für Firefox verwende ich nun ein halb-transparentes Hintergrundbild (normales stylesheet) und für IEv6 wird das normale Bild geladen und dies dann mittels Javascript transparent gemacht (stylesheet speziell für IEv6 & die oben genannte JSFunktion).Den http://de.selfhtml.org/css/eigenschaften/filter.htm#alpha@title=alpha-Filter für den IE kannst du auch im IE-Stylesheet notieren. Eigentlich ist die Filter-Geschichte in erster Linie eine (Microsoft-eigene) CSS-Technik. Oder warum der Filter zwingend mittels JavaScript gesetzt werden? So ganz verstehe ich die Notwendigkeit des Scriptes nicht. Das ginge doch z.B. mit einer Klasse, die den Filter zugewiesen bekommt, viel einfacher.
Es gibt aber auch komplexere Scripte, die automatisch alle eingebundenen halbtransparenten PNGs im IE mit dem AlphaImageLoader-Filter »reparieren«, z.B. http://www.dillerdesign.com/experiment/DD_belatedPNG/.
Mathias
-
-
-
-
-
-
hi,
ich bin jez schon die ganze Zeit am überlegen, wie ich eine Javascript-Funktion automatisch aufrufe (also direkt, wenn die Seite mit dem Script geöffnet wird).
Notiere an geeigneter Stelle, z.B. im Header:
<script type="text/javascript">
meineFunktion();
</script>und die Funktion "meineFunktion();" wird beim Laden der Seite in einem Browser, der JS unterstützt, ausgeführt, sofern es die Funktion auch gibt.
Ein besserer Stil finde ich, ists jedoch, dafür das OnLoad-Event zu nutzen, allein schon, wegen der Übersicht.
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.