blog.t8d.de

Habe gerade bei Google nach “PDT” gesucht, dem PHP Plugin für Eclipse und diese Suchergebnisse bekommen:

Eine ganze Reihe an “social” Elementen sind dazugekommen: promote (der Pfeil), remove (x) und comment (Sprechblase). Sieht so aus als ob Google daran arbeitet, seine Suchergebnisse mithilfe der User weiter in der Relevanz zu verbessern. Gefunden in der englischen Google Suche, eingeloggt mit google Account.

Update: auch im Footer hat sich was geändert. Man kann zu seinem “SearchWiki” wie Google das Ganze anscheinend nennt,  nun auch selbst Ergebnisse hinzufügen. Weiß jemand schon, ob/wie sich das Ganze auf die normalen Google Ergebnisse auswirkt?

Dies sind die Folien zum TMAPI 2.0 Tutorial auf der TMRA 2008. (Auf Folie 22 muss es korrekterweise heißen: assert aTopic.getItemIdentifiers().size() == 1; danke, Lars)

Helge hatte neulich ja hier schon einmal was über die Regex Patterns in der routing.yml von Symfony geschrieben.
Nachdem ich heute fast wieder verrückt geworden bin, habe ich nun ein paar sinnvolle Dinge herausgefunden:

Ich habe versucht folgendes Pattern zu matchen:

numerischeId-UrlSafeTitle

Doch egal welches Pattern ich dafür verwenden wollte – wenn ich im Cache in die generierte Datei config_routng.yml.php schaute, wurde der zweite Teil meines Patterns immer auf mysteriöse Weise geändert:

Dies funktioniert:

id_title_route:  url: /:resourceIdTitle

param: { module: forum, action: view}

  requirements: { respurceIdTitle: ^[0-9]+-.w+ }

und ergibt genereriert im php File:

'resourceIdTitle' => '^[0-9]+-.w+',

Also Zahlen gefolgt von einem Bindestrich gefolgtvon Buchstaben. Leider matchen so noch keine Urls mit  Bindestrichen

Dies funktioniert nicht:

requirements:  { respurceIdTitle: ^[0-9]+-.[w-]+ }

Daraus wird:

'resourceIdTitle' => '^[0-9]+-.[0-9]+',

Merkwürdigerweise wird die zweite Chracter Class (das in den eckigen Klammern) immer zu “0-9″ konvertiert. Ich habe noch einige andere Lösungen probiert (z.B. ^[0-9]+-[^\/]*+) ,  die leider aber alle fehlschlugen mit dem selben merkwürdigen Ergebnis. Letztlich bin ich dann auf die Idee gekommen, einfach mal eine andere YML Syntax auszuprobieren:

id_title_route:  url: /:resourceIdTitle

param: { module: forum, action: view}

requirements:

  resourceIdTitle: "[0-9]+-[w+-]+"

Beim Definieren von Regex-Patterns in der routing.yml sollte man also immer diese Syntax benutzen, dann bleiben die Anweisungen so erhalten, wie man sie geschrieben hat. Ich hoffe damit ist das Thema ein für allemal vom Tisch

Zum Testen habe ich übrigens diesen Online Regex Tester benutzt, den ich sehr empfelen kann, falls es mal irgendwo hakt.

Update: die kurze Syntax funktioniert ebenfalls, wenn man die Regular Expression in Quotes setzt, nutzt man die lange Syntax, sind die Quotes nich erforderlich

Ich habe in letzter Zeit verstärkt Probleme mit Firebug gehabt und der Fehlermeldung “window.console is undefined”. Das lag daran, dass ich in meinem Javascript eine Funktion eingebaut habe, die mal auf der Firebug Website zu finden war (Firebug XS) und verhindern soll, dass es bei Browsern, die kein “console” unterstützen, zu Fehlern kommt.
Leider funktionierte der alte Code bei mir nicht mehr zuverlässig, weshalb ich ihn folgendermaßen geändert habe:

//prevent errors in browsers that do not support console.
if (typeof window.loadFirebugConsole == "undefined" || typeof window.console == 'undefined' ) {
  var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
  window.console = {};
  for (var i = 0; i < names.length; ++i) {
    window.console[names[i]] = function(){};
  }
}

So kann man ohne Probleme Debug Statements im Code stehen lassen, ohne dass es in Browsern, die keinen Firebug unterstützen (z.B. Internet Explorer) zu Problemen kommt.

Update: Habe den Code noch leicht modifiziert, da es noch in einigen Fällen zu Fehlern kam, die entscheidende Zeile ist:

typeof window.loadFirebugConsole == "undefined" || typeof window.console == 'undefined'