Actually its all said on the post itself: installation, features and restrictions.
So go and read it.

Its still a bit early stage and only runs on a nightly-build netbeans but it already has some helpful features.

For me i just like to have a node.js icon as my project icon ;).
No serious, i like the npm support, see image, especially for browsing the modules to see what is all available.

Whats also is nice and that you have the modules in the file tree and that they show the module info.

A GUI for installing the modules and editing the package file i dont really need but its nice to have.
Then starting the app from a button in netbeans is also nice.

I guess whats missing the most is code completion, maybe that will be added sometime soon.
I hope so, because having code completion for node modules would be pretty cool.

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('https://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 :)

Alles was man beachten muss ist eigentlich nur die ignores für git richtig zu setzen.
Hier mal meine Ignore List:

In der root Ebene des Projekts ein .gitignore file anlegen mit diesem Inhalt:

cat .gitignore
*.log
*~
.project
.buildpath
.settings/*

#symfony
config/databases.yml
config/properties.ini
cache/*
log/*
data/*.db

Das sind so die Standards, also alle Log files, die Eclipse spezifischen Projekt Files und die Standard Editor backup-files (die mit der Tilde).
Dazu noch ein die symfony Files und Directories, die man am besten nicht mit versionieren sollte.

Für Symfony selber benutze ich dann noch ein Plugin, welches sich um die autogenerated Files kümmert.
sfSCMIgnoresTaskPlugin
Diese sollte man auch nicht mit versionieren, warum steht hier.
Da nach jedem autogenerate sich die Verzeichnis Struktur ändert, führt man einfach das Plugin aus

symfony util:generate-ignores --add-ignores git

und schon sind all diese Files auch auf ignore:

model/om, model/map, form/base, filter/base
doctrine/base, Plugin/base

Zusätzlich legt es auch noch ignores für die Standard ignore Kandidaten in symfony an.
Redundant zu oben zwar, aber doppelt hält besser ;)

Zwei Sachen sind mir dabei aufgefallen die evtl verbesserungswürdig sind:
1. das Plugin setzt auch die ProjectConfiguration.class.php auf ignore, was mir nicht ganz klar ist?
2. berücksichtigt es keine sqlite *.db files im data dir. ich denke das wird in der nächsten Version mit drin sein.

Mit der WebCam wird die Absicht des Users erkannt und nur ein Event getriggert wenn der MouseOver wirklich gewollt ist.

Möglicherweise ist es technisch etwas anders gelöst. Aber der Effekt ist gut!

Hier ein Entwurf für ein FormWidget, Plugin das seine eigenen Ajax Actions haben soll.
Also erstmal

/plugins/myMightyWidget 

anlegen.

Die Struktur darin sieht dann nachher so aus:

./lib/myMightyWidget.class.php            
./modules/myMightyWidget/actions/actions.class.php
./modules/myMightyWidget/templates/_myMightyWidget.php       
./modules/myMightyWidget/templates/myajaxactionSuccess.php
( ./web/css/myMightyCSSFile.css )
( ./web/js/myMightyExternalJSFile.js )

als erstes:

/plugins/myMightyWidget/lib/myMightyWidget.class.php

Das Template HTML schreiben wir in ein Partial das wir dann nachher in der render-Methode holen.
Dafür müssen wir uns eben den Partial Helper laden, von Haus aus gibt es die Funktion nicht in der Widget Klasse.
Falls unser Widget einen eigenen Stylesheet und auch eine eigene JS Datei haben möchte, könnten wir die beiden auch bequem im entsprechenden myMightyWidget/web Ordner unterbringen. Und auch via den getStylesheet/ getJavascripts Methoden laden lassen.

/plugins/myMightyWidget/lib/myMightyWidget.class.php

class myMightyWidget extends sfWidgetForm
{
	
  public function configure( $options = array(), $attributes = array() )
  {
  	
  	$this->addOption(  "someOption" );
  	
  	$this->addOption(  "someOtherOption", "default" );
  }
  
  public function getStylesheets()
  {
    return array(
    	'/myMightyWidget/css/myMightyWidget.css' => ''
    );
  }
  
  public function getJavascripts()
  {
    return array(
    	'/myMightyWidget/js/myMightyWidget.js'
    );
  }
  
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {
  	
        //load partial Helper as we want to outsource the Template
	sfContext::getInstance()->getConfiguration()->loadHelpers('Partial');
  	
  	
    $options = array(
        'someOption'           => $this->getOption('someOption'),
        'someOtherOption'  => $this->getOption('someOtherOption')
    );
    
  	return  get_partial( 'myMightyWidget/myMightyWidget', $options );
  }
  
}

dann brauchen wir den modules Ordner, hier schonmal für das Partial template
also den Ordner

/plugins/myMightyWidget/modules/myMightyWidget

anlegen.

Darin dann das Partial “_myMightyWidget.php” anlegen:

(ich setze aus Schreibfaulheit einfach mal jQuery voraus …)

<script type="text/javascript">

	$(document).ready(function() {
            $("#myMightyWidget").find(".ajaxResults")load( '<?php echo url_for( "myMightyWidget/myAjaxAction" ); ?>' );
        });
		
</script>

<div id="myMightyWidget">

    Hello ...

    <div class="ajaxResults"></div>

</div>

Für die Ajax Daten dann Action und Template anlegen:

/plugins/myMightyWidget/modules/myMightyWidget/actions/actions.class.php

class myMightyWidgetActions extends sfActions
{
	
	public function executeMyAjaxAction( sfWebRequest $request )
 	{
 		$this->world = "World";
    	}
	
 }

und das Template:

/plugins/myMightyWidget/modules/myMightyWidget/templates/myajaxactionSuccess.php

<strong>
    <?php echo $world; ?>
</strong>

Dann in der app, wo wir das Widget benutzen möchten einfach das Modul “myMightyWidget” aktivieren (settings.yml).
Und das Widget im Template oder direkt in einer Formklasse einbinden.
Und man kann sich mitten im Formular durch irgendwelche Ajax Listen blättern, oder was einem eben einfällt.

Um die Ergebnisse dem generierten Formular “unterzuschmuggeln” muss man nur via JS inputs mit den entsprechenden Namen erzeugen, dann wird das ganz normal mitverarbeitet.
zB.

<input type="hidden" name="project&#91;mitarbeiter_list&#93;&#91;&#93;" value="<?php echo $mitarbeiter_id ?>" />

Klingt komplizierter als es ist. Im einfachsten Fall wird jemand der

http://www.domain.com

aufruft, auf

http://domain.com

umgeleitet. Klappt auch ganz hervorragend.

…

Ausser wenn nach dem redirect das “www.” aus irgendeinem Grund zwar aus der URL, aber nicht aus dem http-Header verschwinden möchte  Dann wird WordPress schön weiter redirecten und fertig ist die Endlosschleife.

Ausführlicher erklärt ist das alles hier.
Dort hat Schnurpsel der Autor hat auch direkt ein WordPress Plugin (123 True HTTP Host 0.10), was diese Merkwürdigkeit 1a ausbügelt.