annett: Javascript läuft beim Debuging mit Firebug anders als ohne

Hallo Leute!
Ich versuche gerade eine Website zu erstellen und stehe beim Debuggen des Javascripts vor einem Problem, welches ich mir nicht erklären kann. Wenn ich im Firefox-Addon Firebug Beakepoints setze und meine js-Funktionen Schritt für Schritt durchgehe läuft alles so ab wie sein sollte. Wenn das ganze ohne Firebug laufen lasse oder die Breakepoints nicht an den entscheidenden Stellen setze, passieren Dinge, die mir unerklärlich sind.

die entsprechenden JS-Funktionen sehen in etwas folgendermaßen aus:

  
		function BrowserCheck()  
  
		{  
  
			var xmlhttp;  
  
			if (window.XMLHttpRequest)  
  
			{  
  
				xmlhttp=new XMLHttpRequest();  
  
			}  
  
			else  
  
			{  
  
				xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  
  
			}  
  
			return xmlhttp;  
  
		}  
  
		function BildExist(Bild, Projekt)  
  
		{  
  
		var exist;  
  
		var xmlhttp = BrowserCheck();  
  
  		xmlhttp.onreadystatechange=function()  
  
			  {  
  
				if (xmlhttp.readyState==4 && xmlhttp.status==200)  
  
				{  
  
					if(xmlhttp.responseText=='true')  
  
						{exist = true;}  
  
					else  
  
						{exist = false;}  
  
				}  
  
			  }  
  
					  xmlhttp.open( 'GET', 'http://testseite.de/DatExist.php?dat='+Bild+'.jpg&pro='+Projekt, true );  
  
					  xmlhttp.send();  
  
		return exist;			  
  
		}  
		function Bildwechsel(Projektname, Bildname)  
  
		{  
  
			var exist = BildExist(Bildname, Projektname);  
  
			if(exist == true)  
  
				{  
  
					document.getElementsByName(Bildname)[0].style.visibility = "visible";  
  
					document.getElementsByName(Bildname)[0].src="Bilder/"+Projektname+"/"+Bildname+".jpg";  
  
				}  
  
				else  
  
				{  
  
					document.getElementsByName(Bildname)[0].src="";  
  
					document.getElementsByName(Bildname)[0].style.visibility = "hidden";  
  
				}  
  
		}  

und die DatExist.php hat in etwa folgenden Inhalt:

  
<?php  
  
$dat = $_GET["dat"];  
  
$pro = $_GET["pro"];  
  
$filename = $_SERVER["DOCUMENT_ROOT"].'/Bilder/'.$pro.'/'.$dat;  
  
if(file_exists($filename))  
  
{echo 'true';}  
  
else{echo 'false';}  
  
?>  

Wenn ich jetzt bei der Funktion BildExist Breakpoints setze läuft alles normal durch. Wenn die diese Punkte aber nicht setze, bekommt die Variable exist in der Funktion Bildwechsel einen undefinierten Wert. Weiß jemand von euch woran das liegen könnte? ich habs schon mit verschiedenen Rechner und Browsern getestet aber es kommt immer das Gleiche raus.

  1. Hallo,

    Wenn das ganze ohne Firebug laufen lasse oder die Breakepoints nicht an den entscheidenden Stellen setze, passieren Dinge, die mir unerklärlich sind.

    ja, du hast ein Problem mit dem Verständnis der zeitlichen Abläufe.

      function BildExist(Bild, Projekt)  
      {  
      var exist;  
      var xmlhttp = BrowserCheck();  
    

    Du deklarierst eine lokale Variable, die nachher das Funktionsergebnis speichern soll ...

    xmlhttp.onreadystatechange=function()
      {
    if (xmlhttp.readyState==4 && xmlhttp.status==200)
    {
    if(xmlhttp.responseText=='true')
    {exist = true;}
    else
    {exist = false;}
    }
      }

    ... gibst dem XHR-Objekt eine Callback-Funktion, die irgendwann später aufgerufen wird, wenn die angeforderte Ressource eintrifft, ...

      			  xmlhttp.open( 'GET', 'http://testseite.de/DatExist.php?dat='+Bild+'.jpg&pro='+Projekt, true );  
      			  xmlhttp.send();  
      return exist;  
    

    ... und gibst die deklarierte Variable zurück, ohne ihr bisher einen Wert zugewiesen zu haben. Sie ist daher undefined.

      function Bildwechsel(Projektname, Bildname)  
      {  
      	var exist = BildExist(Bildname, Projektname);  
      	if(exist == true)  
    

    "Ist es wahr, dass exist wahr ist?"
    Diese Abfrage ist Nonsense; ein einfaches

    if (exist)

    ist leichter zu lesen und bedeutet genau dasselbe. Auch in der anderen Funktion weiter oben machst du es dir unnötig kompliziert:

      			if(xmlhttp.responseText=='true')  
      				{exist = true;}  
      			else  
      				{exist = false;}  
    

    Diesen Block kann man wesentlich einfacher und übersichtlicher schreiben:

    exist = (xmlhttp.responseText=='true');

    Sogar die Klammern sind hier unnötig und dienen nur der besseren Lesbarkeit.
    Apropos übersichtlich: Vielleicht findest du es übersichtlich, in deinem Programmcode immer doppelte Zeilenumbrüche zu machen - für mich bewirkt es das Gegenteil. Einen doppelten Zeilenumbruch (d.h. eine Leerzeile) mache ich nur da, wo auch von der Programmstruktur her ein "Schnitt" sein könnte. Dann erleichtert es tatsächlich das visuelle Erfassen der Struktur.

    Wenn ich jetzt bei der Funktion BildExist Breakpoints setze läuft alles normal durch. Wenn die diese Punkte aber nicht setze, bekommt die Variable exist in der Funktion Bildwechsel einen undefinierten Wert. Weiß jemand von euch woran das liegen könnte?

    Ja, du versuchst, das Ergebnis eines Vorgangs zu lesen, bevor dieser Vorgang stattgefunden hat.

    So long,
     Martin

    --
    Chef zum Bewerber: Es gibt zwei Dinge, auf die ich allergrößten Wert lege. Das eine ist Sauberkeit! Haben Sie übrigens die Schuhe auf der Matte abgetreten? - Ja, selbstverständlich. - Gut. Das andere ist uneingeschränkte Ehrlichkeit. Übrigens, draußen liegt gar keine Fußmatte.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1.   	if(exist == true)  
      

      "Ist es wahr, dass exist wahr ist?"
      Diese Abfrage ist Nonsense;

      Nein. Sie ist in diesem konkreten Fall unnötig explizit und durch if (exist) austauschbar.

      ein einfaches

      if (exist)

      ist leichter zu lesen und bedeutet genau dasselbe.

      Nein, es bedeutet nicht dasselbe.
      Vgl.
      http://aktuell.de.selfhtml.org/artikel/javascript/objektabfragen/#obj
      http://aktuell.de.selfhtml.org/artikel/javascript/objektabfragen/#true

      Mathias

      1. Hallo,

          	if(exist == true)  
        

        "Ist es wahr, dass exist wahr ist?"
        Diese Abfrage ist Nonsense;
        Nein.

        dann haben wir vielleicht unterschiedliche Ansichten davon, was alles zu Nonsense gehört, denn ...

        Sie ist in diesem konkreten Fall unnötig explizit

        ... unnötige Verkomplizierungen zähle ich dazu - so wie ich es auch als Nonsense bezeichnen würde, am "Mittelstück" einer T-Kreuzung ein Schild aufzustellen, das nur Rechts- und Linksabbiegen erlaubt. So einen Fall gibt es übrigens hier in meinem Wohnort:

        Wie gesagt: Möglich, aber sinnlos. Nonsense.

        ein einfaches
            if (exist)
        ist leichter zu lesen und bedeutet genau dasselbe.
        Nein, es bedeutet nicht dasselbe.

        Unter der Maßgabe, dass exist einen boolschen Wert hat, was hier eigentlich beabsichtigt war, ist es dasselbe. Wenn man den Fall einschließt, dass es auch undefined sein könnte, ist die Kurzschreibweise sogar günstiger, weil sie keinen Javascript-Error wirft.

        http://aktuell.de.selfhtml.org/artikel/javascript/objektabfragen/#obj
        http://aktuell.de.selfhtml.org/artikel/javascript/objektabfragen/#true

        Dieser Unterschied ist mir bekannt, er ist hier aber nicht relevant.

        Ciao,
         Martin

        --
        Fische, die bellen, beißen nicht.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. Unter der Maßgabe, dass exist einen boolschen Wert hat, was hier eigentlich beabsichtigt war, ist es dasselbe.

          Wie gesagt, in diesem konkreten Fall ist es austauschbar, im Allgemeinen nicht.

          Wenn man den Fall einschließt, dass es auch undefined sein könnte, ist die Kurzschreibweise sogar günstiger, weil sie keinen Javascript-Error wirft.

          Weder if (foo) noch if (foo == true) werfen eine Exception, wenn foo eine deklarierte Variable mit dem Wert undefined ist. Beide werfen einen ReferenceError, wenn der Identifier in der Scope Chain nicht aufgelöst werden konnte.

          Mathias

  2. Moin!

    Mal so ganz grundsätzlich zu deinem Code-Erscheinungsbild:

    1. Zu viele Leerzeilen! Code geht von Haus aus schon in die Länge, überflüssige Leerzeilen sorgen nur für unnötiges Scrollen.
    2. Setze die geschweiften Klammern in Javascript immer an das ENDE der Zeile, nicht nach einem Return in eine neue Zeile. Spart dir die verzweifelte Suche nach Fehlern, weil Javascript fehlende Semikolons am Befehlsende ergänzen kann.
    3. Die Einrückung habe ich auch schon konsequenter gesehen.

    Und für alles das ist "Ich bin grad am Fehlersuchen, hauptsache es läuft erstmal" keine gute Ausrede.

    Zu deinem Problem: Du hast ein Zeitproblem.

    Du startest einen Ajax-Request, der aber eine gewisse Zeit zur Abarbeitung benötigt, erwartest aber das Ergebnis sofort. So, wie du dein Skript organisiert hast, wird das aber nie funktionieren können.

    Abgesehen davon macht dein PHP-Skript nichts, was man auch mit Ajax direkt beim Server abfragen könnte, denn die Bilder sind ja als HTTP-Ressource verfügbar - oder eben auch nicht. Man kann also anstatt des Aufrufs des PHP-Skripts auch direkt einen HEAD-Request auf die tatsächliche Bild-URL machen und kriegt vom Server dann entweder Status 200 zurück, oder einen Fehlerstatus (404 z.B.).

    Da du aber ohnehin die Bilder direkt danach auf der Seite anzeigen willst, kann man sich das ganze Ajax-Abfragen auch insgesamt sparen, und stattdessen ganz klassisch eine Bild-Ressource im Browser erzeugen, dann genauso abwarten, bis die geladen wurde, und beim Lade-Erfolg hat der Browser das Bild dann schon im Cache.

    Oder noch viel verrückter: Das PHP-Skript erzeugt schon direkt beim Seitenaufruf eine Liste der ihm bekannten Bilder dieser Anzeige-Sequenz und schreibt eine solche Liste für Javascript erreichbar in einen <script>-Bereich in eine Variable (in PHP eignet sich json_encode() perfekt für den Export von Variablen in gültigen Javascript-Variablendefinitions-Code.

    Genau DANN hättest du erst die Möglichkeit, in den bestehenden Funktionen ohne viel Aufwand und insbesondere ohne Ladeverzögerung sofort zu wissen, ob ein Bild existiert, oder nicht. Die Funktion BildExists() würde dann in der Liste nachgucken und sofort true/false zurückgeben können, und müsste nicht einen Callback erzeugen, der erst nach dem erfolgreichen Abarbeiten des Ajax-Requests aufgerufen würde.

    - Sven Rautenberg

    1. @@Sven Rautenberg:

      nuqneH

      1. Setze die geschweiften Klammern in Javascript immer an das ENDE der Zeile, nicht nach einem Return in eine neue Zeile.

      Einspruch, Euer Ehren! Ich finde Allman-Stil nicht nur in CSS, sondern auch in Programmiersprachen wie JavaScript, PHP, C etc. übersichtlicher.

      Qapla'

      --
      Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
      (Mark Twain)
      1. Moin!

        @@Sven Rautenberg:

        nuqneH

        1. Setze die geschweiften Klammern in Javascript immer an das ENDE der Zeile, nicht nach einem Return in eine neue Zeile.

        Einspruch, Euer Ehren! Ich finde Allman-Stil nicht nur in CSS, sondern auch in Programmiersprachen wie JavaScript, PHP, C etc. übersichtlicher.

        Douglas Crockford hat dagegen relativ gute Argumente gebracht.

        Was wäre denn deine Meinung zu diesem hier:

        function foo(a)  
        {  
          if (a == 1)  
          {  
            return  
            {  
              bar : "baz"  
            };  
          }  
          return;  
        }  
        
        

        - Sven Rautenberg

        1. @@Sven Rautenberg:

          nuqneH

          Was wäre denn deine Meinung zu diesem hier:

          Dass man zwischen '{' für Anweisungsblöcke und '{' für Objektliterale unterscheiden muss.

          Qapla'

          --
          Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
          (Mark Twain)
          1. Was wäre denn deine Meinung zu diesem hier:

            Dass man zwischen '{' für Anweisungsblöcke und '{' für Objektliterale unterscheiden muss.

            So würde ich auch argumentieren, auch wenn ich in JavaScript nicht den Allman-Style verwende.

            Aber man sollte schon beachten, was die Motivation hinter den Crockfordschen Regeln ist. Es geht darum, wie viele Programmierer mit unterschiedlichem Erfahrungsstand gemeinsam an großen JavaScript-Anwendungen arbeiten können, ohne dass sich Fehler einschleichen. Die »Good Parts« und die JSLint-Erfordernisse sollen vor Unwissenheit und Unachtsamkeit gleichsam schützen. Die Idee ist, dass man »Don't make me think«-Regeln hat, sodass man u.a. nicht über Tokenization bei der Automatic Semicolon Insertion und Mehrdeutigkeiten der JavaScript-Syntax nachdenken muss.

            Von der Warte aus würde ich auch gegen einen Einrückstil votieren, der hier vom Programmierer erwartet, eine »Ausnahme« beim Umgang mit geschweiften Klammern zu machen (auch wenn sie semantisch eben nichts miteinander zu tun haben).

            Mathias

      2. Bounjoun Gunnar Bittersmann,

        Allman-Stil nicht nur in CSS, sondern auch in Programmiersprachen wie JavaScript, PHP, C etc. übersichtlicher.

        Die regelrechte Ansichtssache.

        Mehr als zwei Leerzeichen für eine Einrückung sind Humbug, Tabs sind Tabu (weil jeder Editor was anderes draus macht, je nach User-Einstellung).

        Der von Sven gezeigte Stil entspricht dagegen eher meiner Gewohnheiten:

        bei kurzen Zeilen gibts die geschweifende Klammer sofort, dann zwei Leerzeichen.

        Bei längeren Statements kann (muss nicht) man die erste geschweifte Klammer nach einem Zeilenumbruch notieren.

        Jedenfalls für mich gilt: Tabs (oder) mehr als zwei Leerzeichen für eine Einrückung macht Quelltext/Programmcode unübersichtlich.

        Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat), kaputt.

        Fazit: Tabtaste ist beim Coden für die Katz'

        Adiou.

        --
        Ich bin eigentlich ganz anders, aber ich komme so selten dazu. - Ödön von Horwáth
        Ist Rudi Carrell Gott? Oder George Harrison Ford?
        Ich bin faul und das ist gut so.
        1. Bounjoun Essenkocher,

          ups,

          Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat), kaputt.

          dieser Satz auch kaputt. Deswegen hier nochmals:

          Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat) die selbe Datei öffnet. Die Einrückungen sind dann kaputt.

          Hab's!

          Wünscht mir guten Abo (Wurstschneckchen mit BraKa aus der Packung - ja, habt ihr gedacht, ich schäle noch selbst?) ;)

          Adiou.

          --
          Ich bin eigentlich ganz anders, aber ich komme so selten dazu. - Ödön von Horwáth
          Ist Rudi Carrell Gott? Oder George Harrison Ford?
          Ich bin faul und das ist gut so.
          1. [latex]Mae  govannen![/latex]

            Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat) die selbe Datei öffnet. Die Einrückungen sind dann kaputt.

            Nein. Sie sind dann genau so, wie *dieser* Programmierer es gerne hätte. Genauso, wie der Programmierer, der nur 2 LZ pro Tab eingestellt hat, den Code genau so zu sehen bekommt, wie er es erwartet und gerne hat. Dahingegeen zwingen führende leerzeichen jedem Programmierer einen ggf. ungewollten Stil auf.

            Fazit: führende Leerzeichen sind  sinnvoll wie Pestbeulen

            Stur lächeln und winken, Männer!
            Kai

            --
            Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
            in Richtung "Mess up the Web".(suit)
            SelfHTML-Forum-Stylesheet
            1. Hallo,

              Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat) die selbe Datei öffnet. Die Einrückungen sind dann kaputt.
              Nein. Sie sind dann genau so, wie *dieser* Programmierer es gerne hätte. Genauso, wie der Programmierer, der nur 2 LZ pro Tab eingestellt hat, den Code genau so zu sehen bekommt, wie er es erwartet und gerne hat. Dahingegeen zwingen führende leerzeichen jedem Programmierer einen ggf. ungewollten Stil auf.

              das ist die Theorie. Die Praxis ist leider, dass viele Programmierer eine Mischung aus Leerzeichen und Tabs verwenden. Und dann ist die Formatierung *wirklich* kaputt, sobald man eine andere Tab-Weite einstellt. Wenn Tabs konsequent verwendet werden, ist das ja noch okay. Aber leider selten.

              Ciao,
               Martin

              --
              Der Dienstweg ist die Abkürzung vom Holzweg zur Sackgasse.
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. [latex]Mae  govannen![/latex]

                Hallo,

                Selber hallo

                Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat) die selbe Datei öffnet. Die Einrückungen sind dann kaputt.
                Nein. Sie sind dann genau so, wie *dieser* Programmierer es gerne hätte. Genauso, wie der Programmierer, der nur 2 LZ pro Tab eingestellt hat, den Code genau so zu sehen bekommt, wie er es erwartet und gerne hat. Dahingegeen zwingen führende leerzeichen jedem Programmierer einen ggf. ungewollten Stil auf.

                das ist die Theorie. Die Praxis ist leider, dass viele Programmierer eine Mischung aus Leerzeichen und Tabs verwenden. Und dann ist die Formatierung *wirklich* kaputt, sobald man eine andere Tab-Weite einstellt.

                Das kann ich nicht als Argument gegen Tabs ansehen. Denn wenn der „Programmierer“ Leerzeichen und Tabs mischt, wird der Code so oder so fehlerhaft angezeigt, außer vielleicht in seinem eigenen Editor, der die Tabs in [latex]n[/latex] LZ wandelt. Alle Anderen, die den Code bearbeiten wollen/müssen und/oder ihn in anderen Programmen laden, die diese Einstellung nicht besitzen oder nicht aktiviert haben, bekommen dann ebenfalls den Code flsach angezeigt.

                Stur lächeln und winken, Männer!
                Kai

                --
                Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
                in Richtung "Mess up the Web".(suit)
                SelfHTML-Forum-Stylesheet
              2. Hi!

                Die Praxis ist leider, dass viele Programmierer eine Mischung aus Leerzeichen und Tabs verwenden. Und dann ist die Formatierung *wirklich* kaputt, sobald man eine andere Tab-Weite einstellt. Wenn Tabs konsequent verwendet werden, ist das ja noch okay. Aber leider selten.

                Die Lösung kann ja nicht "Landstraße für alle" lauten, wenn es viele gibt, die die Autobahnen suboptimal nutzen.

                Eine Lösung für das Tab-Leerzeichen-Mischmasch-Problem wäre Python. Da ist man gezwungen es (zumindest innerhalb einer Datei) einheitlich zu machen, weil sonst die Code-Zugehörigkeit zum Block verloren geht. Allerdings bleibt immer noch das grundsätzliche Tab-vs-Space-Problem bestehen.

                Da der Umstieg auf Python kein allgemein verfügbarer Weg ist, kann man sich zumindest nach IDEs und Editoren (oder Zusätzen für beide) umsehen, die eine Vereinheitlichung mit einfachem Tastendruck vornehmen können.

                Ich mag zum Beispiel den 1TBS. Die Grundeinstellung im Visual-Studio für C# ist jedoch der Allman-Stil, so dass viel Code in dieser Formatierung rumfliegt. Das stört jedoch nur minimal, weil ein kurzes Ctrl+E,C die Formatierung nach meiner Einstellung vornimmt. Das Feature ist so nett, dass ich mir beim Schreiben gar keine Gedanken um korrekte Einrückung machen muss, weil spätestens ein Ctrl+E,C alles in beste Ordnung bringt. ("Spätestens", weil es einige Syntaxelemente gibt, bei deren Eintippen automatisch die aktuelle Zeile formatiert wird, wie beispielsweise beim Semikolon.)

                Lo!

            2. Bounjoun Kai345,

              Die Einrückungen sind dann kaputt.
              Nein.

              Doch.

              Ich benutze mehrere Editoren, und mit Tabs als Einrückung gab's am Ende immer eine verhunzte Datei.

              s. eben audh dem Martin sein Posting!

              Adiou, ohne Tab- und Leerzeichen!

              --
              Ich bin eigentlich ganz anders, aber ich komme so selten dazu. - Ödön von Horwáth
              Ist Rudi Carrell Gott? Oder George Harrison Ford?
              Ich bin faul und das ist gut so.
        2. Hi,

          Allman-Stil
          Die regelrechte Ansichtssache.

          ja, eine Art Glaubenskrieg.

          Mehr als zwei Leerzeichen für eine Einrückung sind Humbug

          Ich habe mich an drei gewöhnt ...

          Tabs sind Tabu (weil jeder Editor was anderes draus macht, je nach User-Einstellung).

          Ja, die mag ich auch nicht.

          Der von Sven gezeigte Stil entspricht dagegen eher meiner Gewohnheiten:

          Meinen auch; öffnende Klammern oder andere "wichtige" Symbole, die einen neuen Denkschritt einleiten, setze ich nie ans Ende der Zeile. Denn da übersieht man sie leicht, ärgerliche Fehler sind damit im wahrsten Sinn des Wortes vorprogrammiert.

          bei kurzen Zeilen gibts die geschweifende Klammer sofort, dann zwei Leerzeichen.

          Hä? Etwa so:?

          if (status=0) { cleanup(); return; }

          Wirkt für mich völlig inkonsequent.

          Bei längeren Statements kann (muss nicht) man die erste geschweifte Klammer nach einem Zeilenumbruch notieren.

          Ich finde, die öffnende Klammer eines Blocks gehört immer an den Zeilenanfang (plus Einrückung).

          Fazit: Tabtaste ist beim Coden für die Katz'

          Nein. Ordentliche Editoren oder IDEs machen aus einem "Tab" automatisch die passende Anzahl Leerzeichen bis zur nächsten Einrückungsebene.

          Wünscht mir guten Abo (Wurstschneckchen mit BraKa aus der Packung - ja, habt ihr gedacht, ich schäle noch selbst?) ;)

          Klingt lecker - ich hatte mein Abendessen heute auch erst gegen halb zwölf. Aber wo gibt es Bratkartoffeln aus der Tube? Das wäre für mich vielleicht auch noch eine Idee.

          Ciao,
           Martin

          --
          PCMCIA: People Can't Memorize Computer Industry Acronyms
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. [latex]Mae  govannen![/latex]

            Der von Sven gezeigte Stil entspricht dagegen eher meiner Gewohnheiten:

            Meinen auch; öffnende Klammern oder andere "wichtige" Symbole, die einen neuen Denkschritt einleiten, setze ich nie ans Ende der Zeile. Denn da übersieht man sie leicht, ärgerliche Fehler sind damit im wahrsten Sinn des Wortes vorprogrammiert.

            Das "Problem" ist, daß der von Sven verwendete Code eben genau *nicht* das macht, was der Programmierer sich gedacht hat. Öffnet man die Klammer hingegen konsequent am Zeilenende, passiert dieser Fehler nicht.

            Stur lächeln und winken, Männer!
            Kai

            --
            Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
            in Richtung "Mess up the Web".(suit)
            SelfHTML-Forum-Stylesheet
        3. @@Jean-Max:

          nuqneH

          Fazit: Tabtaste ist beim Coden für die Katz'

          Deinem Posting fehlen die Ironie-Tags. Am Ende glaubt den Unsinn sonst noch jemand.

          Qapla'

          --
          Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
          (Mark Twain)
        4. @@Jean-Max:

          nuqneH

          Mehr als zwei Leerzeichen für eine Einrückung sind Humbug,

          ACK. Ein oder zwei Leerzeichen aber auch.

          Tabs sind Tabu

          Nein. Leerzeichen sollten Tabu sein.

          (weil jeder Editor was anderes draus macht, je nach User-Einstellung).

          Ja und? Sieh es als Vorteil, nicht als Nachteil.

          Und ja, ich weiß... Tablänge kann man im eigenen Editor einstellen. Die Einstellung ist aber für umme, wenn ein anderer Programmierung mit seinem, anders eingestellten Editor (wo er vielleicht 30Leerzeichen pro Tab hat), kaputt.

          In dem Fall: Jobanzeige.

          Qapla'

          --
          Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
          (Mark Twain)
  3. Hallo,

    du hast anscheinend missverstanden, wie Ajax funktioniert: nämlich asynchron. Du gehst hingegen von einer synchronen Abarbeitung deiner Funktionen aus. Du gehst davon aus, dass BildExist anhand der Serverantwort einen Wert zurückgeben kann. Das funktioniert nicht, da die Funktion sofort nach dem .send() beendet wird und die HTTP-Anfrage im Hintergrund gestartet wird. Das bedeutet, deine BildExist-Funktion wird immer undefined zurückgeben (das ist der Standardwert der Variablen exist, da ihr zu dem Zeitpunkt noch kein Wert zugewiesen wurde).

    Wenn die Serverantwort eingetrudelt ist, so wird die onreadystatechange-Callback-Funktion ausgeführt. Erst daran kannst du mit dem Wert weiterarbeiten. Einfach exist auf true oder false zu setzen, bringt darin nichts, da die äußere Funktion BildExist schon längst durchgelaufen ist. Denn der Browser »wartet« an dieser Stelle nicht auf die Serverantwort, bevor er mit dem Ausführen des JavaScripts fortführt. Klar, wenn du Breakpoints setzt, so sorgst du künstlich dafür, dass der Browser wartet.

    Du müsstest das Program also anders strukturieren. Du kannst z.B. eine anonyme Callback-Funktion an BildExist übergeben, welche den exist-Wert übergeben bekommt und die gewünschten Änderungen vornimmt:

    BildExist(Bildname, Projektname, function (exist) {  
       var bild = document.getElementsByName(Bildname)[0];  
       if (exist) { ... } else { ... }  
    });
    

    BildExist nimmt diese Funktion z.B. als Parameter »callback« entgegen und führt sie aus, sobald die Serverantwort eingetroffen ist:

    function BildExist(Bild, Projekt, callback) {  
       ...  
       xmlhttp.onreadystatechange = function() {  
          if (xmlhttp.readyState == 4) {  
             if (xmlhttp.status == 200 && xmlhttp.responseText == 'true') {  
                callback(true);  
             } else {  
                callback(false);  
             }  
          }  
       };  
       ...  
    }
    

    Grüße,
    Mathias

  4. ihr habt natürlich alle völlig recht. Ich habe den Faktor Zeit bei einer asynchronen Übertragung komplett vergessen und könnte mich dafür selbst ohrfeigen. Vielen Dank für die Hilfe