symfony und Google Analytics

Ich weiss nicht ob Ihr es wußtet:
Es gibt ein feines Plugin für Google Analytics für symfony.
Kris Wallsmith sei dank.

Da kann man sich fragen, warum denn ein Plugin dafür?
Die paar Zeilen Code kopier ich doch schnell ins Layout.
Über das Plugin kann man jedoch Analytics “environment aware” einbinden.
Man will ja nicht das die Test- oder gar Entwicklungsumgebung die Messung verfälscht.

Continue reading “symfony und Google Analytics”

Selenium functional tests mit PHPUnit

PHPUnit hat coolerweise eine Extension für Selenium Tests.

Dafür braucht man noch den PHP Client für die Selenium Remote Control.

pear install Testing_Selenium-0.4.3

Bei mir auf Debian Lenny, bzw. Mac OSX musste ich noch den include_path dafür anpassen,
damit phpunit Testing/Selenium.php gefunden hat.

Damit kann man mit PHP komfortabel einen Selenium Test Server über die Selenium RC ansprechen,
der dann beliebige Browser für functional Tests benutzt.

Der Selenium Server ist auch im Prinzip schnell installiert
und lokal ist das ganze einigermaßen unproblematisch, weil man ja schon mal die Browser seines OS zur Verfügung hat.

In einem Continuous Integration Setup möchte man aber vielleicht Selenium lieber auf einem Web Server laufen lassen.

Da sieht es dann erstmal weniger gut aus mit Browser executables.
Was also tun?

Continue reading “Selenium functional tests mit PHPUnit”

Schau auf die Error_Log

Man sollte sich tatsächlich angewöhnen beim Entwickeln immer eine Console offen zu haben und die error_log zu beobachten.

tail -f /var/log/apache2/error_log

Bekommt man nämlich so einen Fehler in der error_log:

ALERT - configured POST variable limit exceeded - dropped variable ...

… bleibt die Seite meistens ohne Fehlerausgabe trotz E_ALL und es passieren komische Dinge.
Dann kann man schonmal eine ganze Weile damit verbringen ganz woanders zu suchen.
Mit offenem error_log wäre das nicht passiert ;).

Continue reading “Schau auf die Error_Log”

Symfony 2 PR3: doctrine:schema:create liefert “No Metadata Classes to process.”

Die Doku stellt in Aussicht, dass man den “normalen” Doctrine-Namespace-Shortcut benutzen kann, also bspw. @Entity anstelle von @DoctrineOrmMappingEntity. Funktioniert aber nicht, weil in irgend einer Service-Configuration dieser Namespace auf einen Alias gemapped wird, der da lautet “orm”. Die Syntax lautet aber nun auch nicht @ormEntity, sondern @orm:Entity. Schreibt man sein Model also bspw. so:

<?php

namespace ApplicationHelloBundleEntity;

/**
 * ApplicationHelloBundleEntityUser
 *
 * @orm:Table(name="users")
 * @orm:Entity
 */
class User
{
  /**
   * @var integer $id
   *
   * @orm:Column(name="id", type="integer")
   * @orm:Id
   * @orm:GeneratedValue(strategy="AUTO")
   */
  protected $id;

sollten alle CLI-Tasks auch wunderbar funktionieren. Es bleibt zu hoffen, dass die DI-Services eine reichhaltige Parameter-Dokumentation spendiert kriegen und das ganze Bundle-System eine transparente, dokumentierte API erhalten (wo zum Teufel liegt in der Sandbox bitte der versprochene Doctrine-Controller?)

Die Einstellung findet sich übrigens in der Service-Configuration unter src/vendor/symfony/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml:

<service id="doctrine.orm.metadata_driver.annotation.reader" class="%doctrine.orm.metadata.annotation_reader_class%">
            <call method="setAnnotationNamespaceAlias">
              <argument>DoctrineORMMapping</argument>
              <argument>orm</argument>
            </call>
        </service>

Ist leicht zu finden, wenn man weiß, wonach man suchen muss. Ich denke, es ist am einfachsten, die Service-Definition des DI-Containers an entsprechender Stelle an seine eigenen Bedürfnisse anzupassen. Wie das zuverlässig und projektübergreifend funktioniert, erkläre ich vielleicht mal, wenn ich’s selbst gerafft hab.

Achso, hier noch der Nebensatz (etwas herunter scrollen), in dem gesagt wird, das Jonathan irgendwann mal das “orm:” Präfix einführt. Symfony 2 ist definitiv noch nicht ready for production (was aber auch niemand behauptet).

Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen

Unter Dependency Injection versteht man heute nicht nur ein einfaches Entwurfsmuster, sondern vor allem Framework-gestützte Mechanismen, die den konkreten Implementierungsaufwand verringern (Entwicklungszeitoptimierung), dem Entwickler bessere Übersicht über Abhängigkeiten zu schaffen (Applicationdesignoptimierung) und die Anzahl der Instanzen gleichen Prototyps zu minimieren (Performanceoptimierung).

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.
Continue reading “Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen”