SELECT INTERVAL '600' SECOND;
Das sieht doch gar nicht soo falsch aus und liefert auch keinen SQL-Fehler zurück. Leider ist das Ergebnis nicht gerade richtig: das Intervall zeigt ’00:00:00′ an.

Richtig wäre es so:
SELECT INTERVAL '600 SECOND';
Und siehe da: das Intervall ist ’00:10:00′, sprich: 10 Minuten. Yay!

• Internet Explorer 6.0 (Win XP)
• Internet Explorer 7.0 (Vista)
• Firefox 3.5.3 (Win XP)
• Firefox 3.0.14 (Debian/Iceweasel)
• Apple Safari 4.0 (Win XP)
• Opera 9.64 (WinXP und Debian)
• Google Chrome 2.0 (Win XP)
• Konqueror 4.3.1 (Debian)

In keinem dieser aufgelisteten Browser gab es ein derartiges Problem! Der einzige Browser, der im Ansatz Schwierigkeiten gemacht hatte, war der Internet Explorer 6.0 – aber nur, weil er die Facebook-Seiten erst gar nicht anzeigen wollte und dann komplett abgestürzt war. Nach dem dritten Versuch hatte er dann die Seite und das Formular ohne zu Mucken dargestellt – und eine Auswahl der Destination zugelassen.

Als ich erfuhr, dass der Kunde den Internet Explorer 8 verwendete, war ich erstmal ratlos, denn ich hatte gerade keinen zur Hand und ich konnte mir beim besten Willen nicht vorstellen, warum eine simple Select-Box ein Problem darstellen sollte. Nach einem Telefonat mit einem Freund, der ein System mit Internet Explorer 8 hatte, wurde mir der Fehler bestätigt. Leider hat das aber nicht erklärt, warum dieser Browser sich so verhielt – vor allem machte mich stutzig, dass die Vorgänger-Versionen ja nicht derartige Probleme aufwiesen.

Mir blieb also nichts anderes übrig, als ein eigenes System mit Internet Explorer 8 zum Experimentieren aufzusetzen. Zum Glück hatte ich noch eine Vista64-Lizenz rumfliegen. Nach etlichen Stunden der Installation und Updates und Probleme mit einer zu kleinen Systempartitionen (30 GB reichen für ein leeres Vista64 nicht aus, wenn man alle Updates inkl. SP1 haben will!), konnte ich endlich rumexperimentieren.

Die Lösung:
Ich kann zwar immer noch nicht erklären, warum sich der IE8 in diesem Fall so merkwürdig verhält, aber ich habe ein Workaround gefunden. Und zwar stellte sich heraus, dass immer nur die erste Select-Box betroffen war. Nachfolgende Dropdowns funktionierten einwandfrei. Mein Workaround: Banal und unschön, aber es funktioniert. Man baue vor der ersten Select-Box eine Dummy-Select-Box ein, die per Style unsichtbar gemacht wird (“display:none”) und siehe da, das Formular funktioniert so, wie erwartet – und der Benutzer kriegt davon normalerweise gar nichts mit.

Mit Variablen verkürzt sich der Query folgendermassen:

Ich muss also nicht mehr den CONCAT-Teil wiederholen, sondern kann ihn in der Variable @v speichern und darf diese Variable sofort verwenden. Im Gegensatz zum Alias, denn der ist frühestens im GROUP-BY-Abschnitt verfügbar .

Hier die offizielle MySQL-Dokumentation zu dem Thema: User-Defined Variables

Seit ein paar Wochen arbeite ich an einem Projekt, welches die Vorgabe hat, komplett in CodeCharge enwickelt zu werden. Dabei bin ich immer wieder an die Grenzen dieses mächtigen Werkzeuges gestossen. Ein häufiges Problem ist für mich, die Custom-Block-Möglichkeiten der Template-Klasse an Stellen zu verwenden, die CodeCharge anscheinend nicht dafür vorgesehen hat und daher nicht ohne weiteres zulässt.

Es gibt drei unterschiedlich zu behandelnde Fälle, Custom Blocks zu plazieren, soweit ich das überblicke:

• in der obersten Ebene, ausserhalb aller Components
  Hier gibt es gar keine Probleme. Man kann seine Custom Blocks einfach definieren:

  <!-- BEGIN mein_custom_block -->
     mein html code undso mit {meine_variable}
  <!-- END mein_custom_block -->
  

  und per benutzerdefinierten PHP-Code z.B. im “Before Show”-Event der Seite so verwenden:

  global $Tpl;
  $first = true;
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  

• innerhalb eines Blockes (z.B. Row) einer Component (z.B. Grid)
  Das funktioniert fast genauso. Man muss der Template-Klasse nur die eigene Block-Variable nennen:

  global $Tpl;
  $first = true;
  $Tpl->SetBlockVar("mein_custom_block","");
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  

  Diese ersten beiden Fälle sind auch dokumentiert: Working with Custom Template Blocks

• innerhalb eines Panels (bzw. Update-Panels)
  Will man einen Custom-Block innerhalb eines Panels verwenden, was ja das Mittel der Wahl sein soll, sobald man ganze Bereiche der Webseite einfach ein bzw. ausblenden muss (z.B. wegen Zugangsberechtigungen), dann funktionieren die ersten beide Vorgehensweisen nicht mehr. Custom-Blöcke werden hier nicht berücksichtigt, ja sogar vor dem Anzeigen entfernt.

  Das liegt daran, dass der Template-Klassen-interne Zeiger auf der darüberliegenden Ebene stehen bleibt, sobald man sich im “before show”-Ereignis des Panels befindet.
  Die Abhilfe dazu sieht so aus, dass man

  1. sich die aktuelle Position des Template-Klassen-Zeigers merkt (in unserem Fall müsste “/main” darin stehen),
  2. dann den Zeiger mit dem Panel-Pfad-Überschreibt (z.B. “/main/Panel mein_panel”),
  3. hier wie bei den anderen beiden Fällen, die Template-Operationen durchführt und
  4. danach den Zeiger wieder auf den ursprünglichen Punkt richtet (also in unserem Beispiel wieder auf “/main”).

  global $Tpl;
  // (1):
  $aktueller_zeiger = $Tpl->block_path;
  // (2):
  $Tpl->block_path = $aktueller_zeiger . "/Panel mein_panel";
  // (3):
  $first = true;
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  // (4):
  $Tpl->block_path = $aktueller_zeiger;
  

  Benötigt man übrigens in seinem Panel lediglich eine Template-Variable (also {meine_variable}) ohne einen Custom-Block, so braucht man sich nicht mit diesem Workaround abgeben. Template-Variablen alleine funktionieren innerhalb von Panels wie gewohnt und völlig problemlos.
  

Zusammengefasst: Das Problem lag daran, dass die externen JavaScript-Dateien nicht geladen werden konnten, stattdessen wurden HTML-Seiten durch ungünstig gewählte mod_rewrite-Regeln geladen, die natürlich einen “syntax error” erzeugten.
Das steht dem Fehlverhalten bei leerem src-Attribut in script-Tags nicht entgegen, denn der Webserver gibt normalerweise eine Standard-Seite (z.B. index.html) zurück, wenn nur ein Verzeichnis aufgerufen wird (bei leerem src-Attribut wird von Webserver automatisch der komplette Pfad der Basis-Seite ohne Dateiname verwendet), oder eben, falls nicht vorhanden, eine Fehler-Seite, die meistens HTML-Code beinhalten und eben nicht JavaScript.

Die Lösung: Man muss nur dafür sorgen, dass alle eingebundenen JavaScript-Dateien auch tatsächlich geladen werden, bzw auch den Inhalt haben, der tatsächlich gebraucht wird.
Bei uns hiess das, die mod_rewrite-Regeln soweit anpassen, dass solche Script-Dateien nicht umgeleitet werden. CodeCharge-seitig wäre das zu aufwendig geworden, denn es handelte sich hier um HTML-Code der von CodeCharge generiert wird und nur schwer beeinflusst werden kann, ohne dass bei neuem Generieren die Anpassungen wieder überschrieben geworden wären.

Es ist aber ganz anders als ich es mir gedacht hatte: onChange funktionierte für meine zwecke überhaupt nicht unter dem IE6, wogegen onClick genau die komplette Funktionalität lieferte, die ich wollte: selbst wenn ein Radio-Button per Space-Taste ausgewählt wird, wird onClick ausgelöst. Genauso verhält es sich mit den Labels, die mit den jeweiligen Radio-Buttons direkt verbunden sind und daher auch das onClick-Ereignis des zugehörigen Buttons auslösen, also nicht nur den blossen Zustand des Buttons mit beeinflussen.

Das Problem ist jetzt gelöst, aber ich bin gerade etwas unschlüssig, ob ich die Logik hinterfragen muss, mit der ich an die Auswahl des Events herangegangen bin, oder ob der IE6 an dieser Stelle einfach falsch reagiert…

Aber schliesslich habe ich alle Systeme anwenden können. Hier sind die Ergebnisse:

Hilbert Kurve:

Streckenlänge: 4 Pixel
Iterationstiefe: 6
Winkel: 90°

Gosper Kurve:

Streckenlänge: 5 Pixel
Iterationstiefe: 4
Winkel: 60°

Peano Kurve:

Streckenlänge: 3 Pixel
Iterationstiefe: 4
Winkel: 90°

Koch Kurve:

Streckenlänge: 3 Pixel
Iterationstiefe: 4
Winkel: 60°

Penta Plexity:

Streckenlänge: 10 Pixel
Iterationstiefe: 3
Winkel: 36°

Pfeilspitze:

Streckenlänge: 5 Pixel
Iterationstiefe: 6
Winkel: 60°

Sierpinskidreieck:

Streckenlänge: 5 Pixel
Iterationstiefe: 5
Winkel: 60°

Sierpinskiteppich:

Streckenlänge: 3 Pixel
Iterationstiefe: 4
Winkel: 90°

Lévy C Kurve:

Streckenlänge: 3 Pixel
Iterationstiefe: 12
Winkel: 45°

Dafür bin ich von einem String ausgegangen, in dem anfangs nur “R” steht.
Den habe ich dann in eine (rekursive) Funktion gesteckt, die in jedem Durchlauf folgende Textersetzung durchführt:

“R” -> “+R––L+”
“L” -> “–R++L–”

Das bedeutet, dass nach einem Durchlauf “+R––L+” im String steht und im nächsten dann “++R––L+–––R++L–+“. Nach 14 Durchläufen hat man dann einen kilometerlangen String aus lauter Plussen, Minussen, Ls und Rs. Diesen String habe ich dann als Anweisung zum Malen verwendet, bei dem die Zeichen folgendermassen interpretiert wurden:

“–”: Zeichenrichtung um 45° nach links drehen,
“+”: Zeichenrichtung um 45° nach rechts drehen,
“L”, “R”: eine Linie einer bestimmten Länge (hier: 2 Pixel) in die aktuelle Zeichenrichtung ziehen.

Das ist eigentlich schon alles. Simpler gehts eigentlich kaum, und trotzdem kommt dann so eine mehr oder weniger interessante Grafik heraus.

Mehr dazu gibts in Wikipedia: Fraktal

Dafür musste ich aber glatt ein kleines bisschen Schul-Mathematik wiederholen, was eigentlich doch immer wieder Spass machen kann.
Konkret habe ich den Computer simple Farne malen lassen. Die auzufrischenden mathematischen Grundlagen waren hierbei Vektoren (z.B. Berechnung von Betrag/Länge und Winkel) oder auch Schlagworte wie Polarkoordinaten bzw Kartesisches Koordinatensystem.

Jedenfalls ist das alles ganz und gar nichts Neues, aber es kann nicht schaden, auch mal mit sowas rumzuspielen

Links ist ein sehr simpler Farn, der dadurch entsteht, dass an eine Linie quasi eine leicht skalierte Kopie eben jener Linie in einem bestimmten Winkel angelegt wird. Dann legt man an die neue Linie wieder eine im gleichen Maße skalierte Version der zweiten Linie an und wiederholt das so lange, bis die Linie nur noch ein Punkt ist und sich kaum noch eine Veränderung im Bild dadurch ergeben kann.
Rechts ist ein etwas komplexerer Farn, bei dem eben immer zwei verschiedene, skalierte Kopien in verschiedenen Winkeln an die Ursprungslinie angelegt werden.

Während ich mit dem simplen Farn noch keine rekursive Funktion benötigt habe, sondern einfach nur eine begrenzte Schleife benutzt habe, musste ich für den zweiten Farn schon eine sich selbst aufrufende Funktion verwenden, was bei einer Tiefe von zwölf Iterationen durchaus einen merklichen Verbrauch an Sytemressourcen zur Folge hat. Dabei ist die Wahl der Skriptsprache PHP vielleicht auch nicht gerade das Optimum für solche Spielereien…