Augenscheinlich unterstützt das Security-Module nur die Authentifizierung via Benutzername und Password. Wie man sich mit einem Benutzernamen ODER der E-Mail-Adresse und einem Password authentifiziert, ist ein wenig versteckt. So gehts:

Schaut man sich den generischen EntityUserProvider an, so sieht man ab Zeile 46 sowas wie

    /**
     * {@inheritdoc}
     */
    public function loadUserByUsername($username)
    {
        if (null !== $this->property) {
            $user = $this->repository->findOneBy(array($this->property => $username));
        } else {
            if (!$this->repository instanceof UserProviderInterface) {
                throw new InvalidArgumentException(sprintf('The Doctrine repository "%s" must implement UserProviderInterface.', get_class($this->repository)));
            }

            $user = $this->repository->loadUserByUsername($username);
        }

        if (null === $user) {
            throw new UsernameNotFoundException(sprintf('User "%s" not found.', $username));
        }

        return $user;
    }

Dieser Code besagt, dass nur dann, wenn die Konfigurationeinstellung “property” aus der security.yml entfernt wird (steht üblicherweise auf “username” und gibt das Datenbankattribut an, das eben den Benutzernamen hält), das entsprechende Doctrine-Entity “User” auch eine Repository-Class hat und diese darüber hinaus UserProviderInterface implementiert, man seine eigene loadUserByUsername()-Methode implementieren kann, die dann von der Firewall zur Identifizierung des Benutzer beim Login herangezogen wird (dieser Vorgang ist komplett intransparent, Symfony Magic).

Also aus seiner “alten” security.yml

    providers:
        default:
            users:
                user:  { password: userpass, roles: [ 'ROLE_USER' ] }
                admin: { password: adminpass, roles: [ 'ROLE_ADMIN' ] }
            entity: { class: DvlpCoreBundleEntityUser, property: username }

sowas machen:

     ...
            entity: { class: DvlpCoreBundleEntityUser }

Dann muss das zu User gehörtige UserRepository nur noch UserProviderInterface implementieren, bspw. so:

<?php

namespace DvlpCoreBundleEntity;

use DoctrineORMEntityRepository;
use SymfonyComponentSecurityCoreUserUserProviderInterface;
use SymfonyComponentSecurityCoreUserUserInterface;

/**
 * UserRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class UserRepository extends EntityRepository implements UserProviderInterface
{
    /**
     * {@inheritdoc}
     */
    public function loadUserByUsername($username)
    {
        return $this->getEntityManager()
            ->createQuery('SELECT u FROM DvlpCoreBundle:User u JOIN u.Profile p WHERE u.username = :username OR p.email = :username')
            ->setParameters(array(
                'username' => $username
            ))
            ->getOneOrNullResult();
    }

    /**
     * {@inheritDoc}
     */
    public function refreshUser(UserInterface $user)
    {
        return $this->loadUserByUsername($user->getUsername());
    }

    /**
     * {@inheritDoc}
     */
    public function supportsClass($class)
    {
        // NEVER CALLED ...
        return $class === 'DvlpCoreBundleEntityUser';
    }
}
}

Schon kann man als Benutzernamen entweder den Username oder die E-Mail-Adresse des Users angeben.

Hallo Welt!
Ich hab einen kleinen Wrapper für die Google Translate API v1 als symfony 1.4 Plugin auf github gehoben:
https://github.com/ivoba/sfGoogleTranslate

Einfach Plugin installieren und dann im Model oder wo es gebraucht wird:

$gT = new sfGoogleTranslate('de','fr');
$t = $gT->translate('Hallo schöne Frau');
echo $t;

Das Plugin nutzt den sfWebbrowser, der ist ja ziemlich praktisch, den braucht man also auch noch.
Die detect Methode wird auch unterstützt.

Evtl. könnte man jetzt noch tasks machen, wie etwas aus dem I18nTranslate Plugin, welcher alle i18n dictionary files übersetzt.

Wer sich berufen fühlt, kann den ja porten und das Ding forken ;)

Sollte man mal eine symfony 1.2.x Anwendung auf symfony 1.4.x migrieren und man stößt auf diesen Fehler:

Class 'sfLoader' not found

Dann hat man versucht einen Helper in der Action zu laden zB so:

sfLoader::loadHelpers('String');

Der sfLoader ist in 1.4 allerdings entfernt worden.
Stattdessen sollte man dann sowas schreiben:

$this->getContext()->getConfiguration()->loadHelpers('String');

Dann klappts.

Ab heute, dem 7. 3. 2011, steht auf http://symfony.com die “Standard-Edition” der neuesten Version 2 des populären RAD-Frameworks zum Download bereit. Bereits am vergangenen Wochenende ging die neue Website des Projekts online.

Symfony 2 wird als Sammlung loser gekoppelter Komponenten – sog. “Bundles” – in mehreren Ausgaben erhältlich sein. Zum jetzigen Zeitpunkt existiert bereits eine Sandbox und eine davon abgeleitete “Standard-Edition”, die wie gewohnt ein festes Code-Verzeichnislayout vorgeben.

Als zukünftige Ausgaben denkbar sind ein Symfony2-basierendes CMF (Content Management Framework) oder eine auf die speziellen Befürfnisse von Online-Shops zugeschnittene Bundle-Sammlung.

Der Code ist noch nicht als stabil deklariert. Die bereits vorhandene und wie immer intensiv gepflegte Referenz-Dokumentation lädt bereits jetzt zum Reinschnuppern und Ausprobieren ein.

Wer sich wundert, woher die beiden Dateien “app/bootstrap.php” respektive “app/bootstrap_cache.php” im Standard-app-Verzeichnis der Sandbox kommen: Das Script unter bin/build_bootstrap.php generiert eben diese aus existierenden Sourcen.

Das Script sollte im Projekt-Rootverzeichnis aufgerufen werden, also etwa so:
$ php bin/build_bootstrap.php
Das ganze dient schlicht dazu, den PHP-Autoloader zu entlasten (und ersetzt somit die core_compile.yml-Konfiguration aus der Symfony 1.x-Welt).

Natürlich spricht nichts dagegen, das Script als Vorlage für seinen eigenen genererate-bootstrap-code zu modifizieren.

d’oh

seit längerem hatte ich erfolglos versucht den Ouput der Symfony Tasks auf meinem Mac farbig dargestellt zu bekommen.

Nach Experimenten mit verschiedenen Color Themes und AddOns für die Terminal.app und / oder iTerm hatte ich dann die tollsten Ansi Farben, Prompts und VI-Themes.

Nur die Symfony Tasks waren immer noch einfarbig.

RTFM….

In dem Fall sogar noch einfacher:
check_configuration.php einfach mal laufen lassen:

php lib/vendor/symfony/data/bin/check_configuration.php

[[WARNING]] The posix_isatty() is available: FAILED
***
Install and enable the php_posix extension
(used to colorized the CLI output)
***

wie gesagt: d’oh.

via macports schnell installiert:

sudo port install php5-posix

und farbiger Output bei allen Symfony Tasks. Und das unter Snow Leopard.
Vielleicht hat das ja noch jemand übersehen und erspart sich hiermit die lange Suche.

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.

Das läuft dann über die app.yml:

prod:
  sf_google_analytics_plugin:
    enabled:      on
    profile_id:   UA-XXXXXXX
    tracker:      google

Außerdem hat das Plugin noch einiges mehr im petto:
Zum Beispiel kann man:

– Seiten mit custom Namen tracken
– Seiten tracken in der action
– Routen kanonisch tracken
– einzelne Module vom Tracking ausschließen
– custom Werte aus der app in der action tracken

Da freut sich wer es braucht…

Hier mal ein Beispiel für einen (via shell script) automatisierten build bei einer PHP, Symfony 1.4 Anwendung mit GIT zur Versionskontrolle.

#wipe old version of build db
mysql -uUSER -pPW drop build-db

#wipe the build workspace
rm -rf ./build-workspace

#checkout the sourcecode
git clone git@my-domain.com:my-repository ./build-workspace

cd build-workspace

#(re)configure database for build server
php ./symfony configure:database "mysql:host=build-db-server;dbname=build-server-sql-user"

#(re)build db
php ./symfony doctrine:build-db

der Einfachkeit halber liegt der zu migrierende sql dump schon im repository.
Könnte man natürlich auch jetzt von remote holen.

#import some test data
mysql -uUSER -pPW --force database_name < data/sql/some_data_to_migrate.sql

hier sollte keine Handarbeit mehr nötig sein,
da man ja alle DB Änderungen per doctrine migrations gemacht hat.
Im Gegensatz zu schema Änderungen bleibt man so abwärtskompatibel zu Vorgängerversionen.

#migrate the test data / db if necessary
php ./symfony doctrine:migrate

zum guten Schluss alles testen

#run test, save results as xml
php ./symfony test:all -xml=path/to/results.xml

Es lohnt sich in mehrfacher Hinsicht wirklich das komplette Projekt inkl. DB automatisiert von 0 installierbar zu machen.
Auch wenn es vielleicht erstmal nur auf ein paar Instanzen laufen soll.

Man kann erstens bei verteiltem Arbeiten schnell mal eine weitere Arbeitskopie auf einem anderen Rechner erstellen.

Zweitens kann man relativ einfach ein continuous integration setup auf die Beine stellen und sofort ruhiger schlafen ;)

Außerdem kann man ständig die Migration von aktuellen Live Daten, oder einer Vorgängerversion in die Entwicklungsversion testen.
“Continuous Migration” ;)

Durch meine ersten Gehversuche mit Grails sowie einen interessanten Vortrag über JSF2 bin ich kürzlich über das Kürzel “IoC” gestoßen. Das ganze ist vom Prinzip her recht einfach und in Grails, das im Grunde ein stinknormales MVC-Pattern implementiert, konkret gelöst, indem man durch eine Namenskonvention am Controller automatisch sogenannte Services instanziiert.

Also anstatt zu schreiben:

class DefaultController {

  def mySuperService

  def index = {
   mySuperService = new MySuperService(params);
   mySuperService.getData()
  }
}

schreibe ich einfach

class DefaultController {

  def mySuperService

  def index = {
   mySuperService.getData()
  }
}

Gut, sieht jetzt nicht besonders spektakulär aus, doch wenn man weiß, dass mySuperService im Hintergrund (Stichwort “Spring Managed Bean”) automatisch instanziiert sowie an meinen Controller gebunden wurde und dass da prinzipiell noch viel mehr geht, ist das bereits ein ganz brauchbares Feature.

Natürlich ist die Injizierung per Naming-convention eine Grails-eigene Lösung (alles, was auf Service endet, ist ein Service und wird injiziert), um Konfigurationsarbeit zu sparen. Für gewöhnlich wird das Verhalten sogenanner “managed Beans” natürlich konfiguriert, entweder Java-typisch via XML-Konfigurationsdatei oder durch Annotationen.

Dabei kann wiederum java-typisch auch der “Scope” einer Bean bestimmt werden; hier bringt vor allem der “Singleton” bzw. Application Scope einen Vorteil gegenüber einer statuslosen PHP-Anwendung. Doch bereits die Fähigkeit, den Scope überhaupt fein granulieren zu können, setzt das ganze wieder von PHP-Gemurkse ala $_SESSION, $_REQUEST etc. ab.

Also egal wo und in welchem Kontext man Managed Beans, Enterprise Java Beans, Spring Beans (Die Unterschiede interessieren hier mal nicht die Bohne – ich könnte sie auch gar nicht qualifiziert erläutern) einsetzt – das IoC-Muster spart Code, vereinfacht Abhängigkeiten und sorgt für schlankere Konstruktoren – ist insgesamt also eine sehr mächtige Sache.

Was aber nicht heißt, dass so etwas generell nicht auch in meiner PHP-Anwendung funktionieren kann.

sfDependencyInjectionContainerPlugin

Dieses Plugin (http://www.symfony-project.org/plugins/sfDependencyInjectionContainerPlugin) leistet genau das: Es verwaltet entweder über eine in PHP formulierte DSL(hust), über XML oder eine symfony-typische .yml-Datei konfigurierte Abhängigkeiten. Das Plugin ist selbst nur ein Adapter, das die Symfony-Komponente DependencyInjection in ein Symfony 1.2 (und höher) Projekt integriert – in Symfony 2.0 wird DependencyInjection voraussichtlich Bestandteil des Systemkerns sein.

Zur Installation und Konfiguration des Plugins verweise ich auf die README-Datei. Trotzdem vielleicht der Hinweis, dass die Bibliotheken mit einem eigenen Autoloader daherkommen, daher empfehle ich, folgende Programm-Zeilen in eure ProjectConfiguration.class.php hinzuzufügen:

config/projectConfiguration.class.php

  require_once dirname(__FILE__) . '/../pfad/zur/DependencyInjection/Komponente/sfServiceContainerAutoloader.php';
  sfServiceContainerAutoloader::register();

Anders habe ich es nicht hinbekommen, zwar lässt sich durch eine config/autoload.yml die Laufzeit von Class Not Found-Fehlern befreien, aber das Symfony Command Line Interface geht dann trotzdem hops. Für einen Tipp, wie man’s eleganter hinkriegt, wäre ich dankbar.

Beispielsweise möchte ich den Nerdpress-RSS-Feed in meine Seite einbinden. Dazu baue ich einen Proxy, um bequem via AJAX auf das entfernte RSS-XML zugreifen zu können.
Diesen Proxy definiere ich als Service und injiziere ihn meine Symfony-Module:

config/services.yml:

services:
  NerdpressRssProxy:
    class: NerdpressRssProxy

Diese drei Zeilen reichen bereits aus, um meine Abhängigkeit zu definieren.

Nun implementiere ich die Service-Klasse:

lib/NerdpressRssProxy.php

class NerdpressRssProxy
{
  /**
   * @var sfFileCache
   */
  protected $cache;

  /**
   * @return sfFileCache
   */
  public function getCache()
  {
    if (null === $this->cache)
    {
      $this->cache = new sfFileCache(array('cache_dir' => sfConfig::get('sf_cache_dir')));
    }
    return $this->cache;
  }

  /**
   * @return string
   * @throws Exception
   */
  public function getEntries()
  {
    $cache = $this->getCache();

    sfContext::getInstance()->getConfiguration()->loadHelpers(array('Helper', 'Tag', 'Url', 'Text'));

    if(!($rss = $cache->get('nerdpress_rss')))
    {
      if(($rss = @file_get_contents('http://nerdpress.org/feed')))
      {
        $rss = auto_link_text($rss, 'all', array('class' => 'external'));

        $cache->set('nerdpress_rss', $rss, 3600);
      }
      else
      {
        throw new Exception('Rss feed could not be opened');
      }
    }
    return $rss;
  }
}

Die Methode getEntries() rufe ich nun in meinem Nerdpress-RSS-Modul auf, um die WebResponse zu befüllen:

apps/frontend/modules/rssProxy/actions/actions.class.php

class rssProxyActions extends sfActions
{
  public function preExecute()
  {
    $this->getResponse()->setContentType('application/rss+xml');
  }

  public function executeNerdpress(sfWebRequest $request)
  {
    try
    {
      // SERVICE HOLEN UND getEntries() AUFRUFEN
      $rss = $this->getService('NerdpressRssProxy')->getEntries();

      $this->getResponse()->setHttpHeader('Content-Length', mb_strlen($rss));
      $this->getResponse()->setContent($rss);
    }
    catch(Exception $e)
    {
      $this->forward404($e->getMessage());
    }
    return sfView::NONE;
  }
}

Das wars. Einfach, oder? Ingesamt 3 Zeilen yml-Konfiguration reichen, um Dependency Injection “the PHP way” zu realisieren, Symfony sei Dank. Natürlich ist nicht *ganz* so hübsch wie in der J2EE-Welt und sicherlich funktional noch weit davon entfernt. Aber ein Anfang ist gemacht, und wenn man seine Services erst einmal auf diese Art und Weise unter Kontrolle bringt, ist man vom Nutzen der Sache schnell überzeugt: Mit ein bisschen Disziplin gehören “Controller-Spaghettiwürste” nämlich der Vergangenheit an.

Bitte entschuldigt eventuell fehlerhafte oder unsaubere Beschreibungen der Begriffe “Bean”, “IoC”, JSF2 etc. Ich bitte explizit um Korrektur in Form von Kommentaren :)

Gerade erst gesehen: Symfony 2.0 kommt anscheinend gegen Ende 2010.

get the code.:)

The repository is updated every 15 minutes.

Einiges klingt schon ziemlich vielversprechend.
…die Tage mal genauer reinschauen.

It is up to 3 times faster than symfony 1.4 or Zend Framework 1.10 and consumes half the memory.