Damit kann man sehr einfach Deeplinks in Ajax getriebenen Seiten realisieren.

So lassen sich zum Beispiel verschiedene Zustände in einer Ajax Seite navigierbar machen, wie zum Beispiel einzelne Tabs via Link öffnen oder auch Akkordion Zustände.
Oder man kann Ajax Bereiche SEO technisch erfassbar machen.

Das Plugin nutzt auch die HTML5 History API, damit werden Ajax Zustände in die Browser History geschrieben, womit sich der Zurück Button dann auch damit nutzen läßt ohne die Seite neu laden zu müssen.
Auch kann man einfach die Url im Address Bar ändern.

Am besten schaut man sich mal die Beispiele auf der Demo Seite an.

Tolle Sache.

Wird JSON mit dem richtigen Header ausgeliefert, unter PHP geht der so:

header('Content-type: application/json');

Dann kann man ein feines Feature von Firebug nutzen:
den JSON View, dieser versteckt sich unter der Response als JSON Tab.

Ja schon besser! Aber, ich wiederhole, nur mit dem richtigen Header, mit text/html o.ä. ist dieser Tab nicht zu sehen.

Nun gut, trotzdem ein bißchen eng da alles in der FireBug Hülle.
Ich mach ja ganz gerne den Ajax Call in einem neuen Tab auf, um zu sehen ob alles drin ist.
Dann empfiehlt sich ein Firefox AddOn: JSONView

Dies rendered das JSON schön im Firefox, wenn , Ihr habts erraten, der Header stimmt: application/json !

So ist gut!

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?

Eine Möglichkeit ist saucelabs.com.
Die bieten “Cross browser testing with Selenium in the cloud” an.
Sogar gratis für Firefox unter Linux.
Für die anderen Browser und OS muss man dann schon auf einen bezahlten Account umsteigen.

Dann einfach den saucelabs Selenium Server mit oben erwähnter Extension aus PHPUnit ansprechen:

Das Example.php Script von saucelabs

require_once 'Testing/Selenium.php';
require_once 'PHPUnit/Framework/TestCase.php';

class Example extends PHPUnit_Framework_TestCase
{
    private $selenium;

    public function setUp()
    {
        $this->selenium = new Testing_Selenium(
            json_encode(array(
                "username" => "YOUR_USERNAME",
                "access-key" => "YOUR_ACCESS_KEY",
                "os" => "Windows 2003", 
                "browser" => "firefox",
                "browser-version" => "3.6.",
                "name" => $this->getName()
            )),
            "http://saucelabs.com", 
            "ondemand.saucelabs.com",
            80,
            90000);
        $this->selenium->start();
    }

    public function tearDown()
    {
        $this->selenium->stop();
    }

    public function testSauce()
    {
        $this->selenium->open("/");
        $this->assertEquals("Cross browser testing with Selenium - Sauce Labs",
                            $this->selenium->getTitle());
    }

}

und PHPUnit macht Selenium Tests:

phpunit Example.php

:)

Bedient man sich herkömmlicher JavaScript-Technik, muss man mit aynchronen Ajax-Requests herumkaspern, sich mit Timeouts, Memory-Leaks und Cross-Domain-Sicherheitspolicen herumschlagen. Und auch hier kommt man nicht herum, den Server zu tweaken oder gleich einen zweiten aufzusetzen, der ausschließlich auf Polls oder Long-Polls trainiert ist.

Gerade in der PHP-Welt ist es nicht einfach, einen üblichen LAMP-Stack soweit zu bringen, dass so etwas auch unter Last funktioniert – Java ist da wie immer weiter und bietet mit JMS ein einheitliches Interface – da gibt es Software für den gewöhnlichen Servletcontainer, im Anwendungsserver muss das laut Spezifikation sogar im Lieferumfang enthalten sein.

Möchte man trotzdem mit “Bordmitteln” mal schnell eine Chatbox aufsetzen, führt Longpolling + Ajax eigentlich schnell zu einem akzeptablen Ergebnis – nichts für Millionen konkurrierende Zugriffe, aber immerhin eine nette Spielerei für zwischendurch. Wäre da nicht ständiges Warten auf die Response, das sich nach einiger Zeit einerseits mit einer merklichen Ruckelorgie bemerkbar macht oder gar den Mauszeiger in eine ewiglich drehende Sanduhr verwandelt.

HTML 5 to the rescue…

HTML 5 kann sogenannte Dedicated Worker – “echte” Workerthreads auf Betriebssystemebene, die man mit einer Zeile spawnen kann.

new Worker('meinScript.js')

Innerhalb eines Threads kann man lang laufende Rechenoperationen im Hintergrund verstecken – warum also nicht auch einen Ajax-Request? Allerdings haben diese Threads einen Nachteil: Aus Sicherheitsgründen laufen sie in einem klar abgegrenzten Scope, in dem sozusagen nichts vorhanden ist. Auch keine Referenz auf das document-Object der Elternseite. Das stoppt die meisten Javascript-Bibliotheken, wie bspw. JQuery. Man muss sich also mit Bordmitteln begnügen.

Eine Methode, die einen Worker initialisiert, könnte so aussehen:

    _initializeLongPoll: function()
    {
      var messenger = this;

      var worker = new Worker('my-ajax-worker.js');
        worker.onmessage = function(event)
        {
          var json = jQuery.parseJSON(event.data);
            
          // NEUE CHAT-NACHRICHT ERZEUGEN
          messenger.$_list.append($('<li class="messenger-list-item">'
            + '<strong class="messenger-list-item-author">' + json.author + '</strong>'
            + '<span class="messenger-list-item-message">' + json.text + '</span></li>'));
        };
    }

“my-ajax-worker.js” ist ausschließlich für den Ajax-Request zuständig. Hier wird ein dynamisches Javascript in einem Symfony-Projekt generiert:

    
    var onLoad = function()
    {
      var output = httpRequest.responseText;
      if (output) {
       
        // DELEGIERT DIE RESPONSE ZURÜCK.
        postMessage(output.trim());
        
        // ERZEUGE NEUEN XmlHttpRequest
        httpRequest = initRequest();
      }
    };

    // WIR SPAREN UND DEN X-BROWSER XmlHttpRequest-KRAM
    var httpRequest = initRequest();

Details zum serverseitigen Script möchte ich an dieser Stelle vernachlässigen, im Grunde funktioniert es folgendermaßen: Es arbeitet so lange, bis eine Änderung festzustellen ist. Erst bei Änderung wird die Response an den Client ausgeliefert (darum heißt es “Long-Polling”, weil ein Request ganz schön lange dauern kann):

while(true)
{
  if(newData())
  {
    return getNewData()
  }
  sleep(5);
}

Der Kram funktioniert natürlich nur in HTML5-Browsern, die das Worker-Objekt unterstützen. Dazu zählen Firefox 3.6, Google Chrome und natürlich Safari. Ob Opera es beherrscht, weiß ich nicht, ob der IE 8 es beherrscht, bezweifle ich. Aber wie gesagt: Es ist nur eine Spielerei und keine produktiv geeignete Anwendung. Demnächst schau ich mir auch mal die WebSocket API an…

Known Issues

Vorsicht mit session_start() und konkurrierenden (asynchronen) HTTP-Zugriffen. Im User-Sessionscope wird der Apache immer auf das Schließen einer Session warten, bis er dem nächsten Request erlaubt, die Session wieder “aufzunehmen”. Und im Normalfall dauert eine User-Session genau so lange wie die Request-Lifetime. Das führt dazu, dass bei 4 gleichzeitig abgefeuerten XmlHttpRequests diese trotzdem als Stack nach dem FIFO-Prinzip abgehandelt werden. Man verliert somit den Vorteil der Asynchronität. Es ist also zwingend erforderlich, die Session bereits vor dem Long-Poll-Loop abzuschließen (durch den Aufruf von session_write_close();

(function($) {

  $('item').each(function() { $(arguments[1]).find('dc\:creator').[...]() } );

})(jQuery);

Dies entspricht wohl rein syntaktisch nicht ganz dem entsprechendem CSS3-Proposal (einzusehen unter http://www.w3.org/TR/css3-selectors/#typenmsp). Ich habe beide Möglichkeiten interessehalber auch einmal in einem aktuellen FF3.6 und Chromium getestet:

<style type="text/css">
/*<![CDATA[*/
  @namespace hanswurst url(https://www.meins.int)

  hanswurst|kaese
  {
    color: red;
  }
/*]]>*/
</style>
<hanswurst:kaese>
  Hanswurst liebt käse
</hanswurst:kaese>

Ergebnis: Naja, klappt nicht. Eventuell hat jemand eine Idee oder kann mich korrigieren?

* Logs all JavaScript errors (local or remote)
* Provides a stack trace to find the cause in all browsers
* Groups errors by cause
* Development and Production modes
* RSS feeds for errors

Einfach einbinden via Javascript im Seitenheader. Dann kriegt man schöne Statistiken über Javascript Fehler mit Browser und OS Infos, Mail-Notifications usw.

Ein bißchen wie Google Analytics.

Das ganze ist (noch) kostenlos während der betaPhase.

Auf die Idee clientseitige Fehler via Ajax auf dem Server zu loggen, wäre ich irgendwie garnicht gekommen. Andere Leute schon.
Trotzdem wundert es mich in Nachhinein fast dass es da nichts verbreiteteres gibt.
Das schreit ja eigentlich nach einem Symfony Plugin, oder?

:)

Dojo Baukausten

Standardmäßig lädt der Dojo-Core alle benötigten Pakete, die mittels dojo.require() angefordert werden, via XmlHttpRequest vom Server. Das kann je nach Projektumfang schonmal einige Sekunden in Anspruch nehmen, wenn plötzlich gefühlte 200 Sub-Requests beim Pageload abgefeuert werden.

Wenn es generell ans Deployment eines Web-Projekts geht, ist man daran interessiert, die Ladezeit von Scriptdateien oder Stylesheets zu minimieren, indem man zum Beispiel im ersten Schritt alle referenzierten Script-/CSS-Dateien in eine große Datei überträgt und damit konsolidiert. Dies kann mitunter mit Aufwand verbunden sein, wenn viele Scripte copied & pasted werden müssen, außerdem scheint diese Vorgehensweise nicht besonders elegant, noch dazu Fehleranfällig.

Im zweiten Schritt nutzt man üblicherweise so etwas wie Code-Obfuscating oder Code-Minimizing. Diese Techniken dienen in erster Linie dazu, die Datenmenge von Script-Quellen zu minimieren und damit die Downloadzeiten zu beschleunigen. Dies geschieht wiederum mit Hilfe von Shellscripten oder Mini-Programmen, die Quelltexte parsen und dann je nach Voreinstellung White-Spaces und Kommentare entfernen oder den ganzen Code überarbeiten, indem bspw. Variablennamen durch möglichst kleine Buchstabenkombinationen ersetzt werden um die Zeilenlänge zu begrenzen. Der Betrachter sieht dann in der Quelltextansicht nur noch eine lange, einzeilige “Code-Wurst”.   “Disassembling” ist hier nur mit Aufwand möglich, aber prinzipiell eben das: möglich.

Die Dojo-Build-Tools automatisieren beide Schritte, wobei Schritt 1, die Code-Konsolidierung, durch das Dojo-Pakagesystem ermöglicht wird und Schritt 2 durch einen eingebauten Obfuscator, alternativ kann der Google Closure Compiler verwendet werden. Die Werkzeuge bestehen aus einigen .jar-Dateien, die in jeder halbwegs aktuellen Java Virtual Machine laufen und mittels $ java –classpath … aufgerufen werden. Ein paar freundlicherweise beigelegte Shellscripte bzw. .bat-Dateien vereinfachen den Aufruf.

Die Datei build.sh beispielsweise benötigt mindestens einen Zielparameter “profile”, der den Pfad zur Profildatei enthält. Diese Datei besteht aus einem JSON-Objekt und konfiguriert die Projektumgebung. Hier kann der Entwickler alle Dateien bzw. Namensräume angeben, die der Compiler berücksichtigen soll.

Optional anzugeben ist die Behandlung von CSS-Dateien, die Code-Minimierungsstrategie und so weiter. Ein $ build.sh liefert eine gut dokumentierte Liste der möglichen Argumente.

Somit lassen sich automatisiert alle eigenen Javascripts und die des Dojo Frameworks zusammen mit CSS-Stylesheets für die Produktionsumgebung “fit machen” und optimieren. Dokumentiert ist das ganze wie immer mäßig auf dem dojocampus.

Dojo und Symfony

Im Entwickleralltag möchte man seine Entwicklungsumgebungen zentral verwalten. Im Symfony-Kontext gibt es bspw. standardmäßig die Environments “Prod”, “Int” und “Dev”. Alle drei Umgebungen nutzen unterschiedliche Datenbanken, Loggingeinstellungen und so weiter. Natürlich liegt es nahe, die einzelnen Dojo-Builds ebenfalls “environment-aware” zu konfigurieren. Dies ist mit einigen einfachen Schritten erledigt, so könnte man bspw. das Script-Verzeichnis umgebungsabhängig verwalten. Doch so richtig optimal ist das nicht, und vor allem: Die Dojo-Build-Tools haben in der Form keine Entsprechnung als Symfony-Task, die Verheiratung wirkt also etwas widerwillig.

In so einem Fall lohnt sich natürlich der Blick ins Symfony Plugin Repository, und siehe da, das sfDojoPlugin erledigt den Job. Installieren, Dojo als Dependency herunterladen (ein großer Vorteil, somit ist man nicht auf eine eventuell veraltete bundled Version angewiesen), Filter einfügen, fertig. Schon gibt es einen neuen Symfony Task Namespace “dojo”.

$ symfony dojo:build-for-prod

kompiliert dann die Javascripts für die Produktionsumgebung, ohne dass zusätzlicher Konfigurationsaufwand anfällt. Das ganze funktioniert durch eine Namensraum-Konvention der Ordner, in denen das Plugin einerseits die Dojo-Sourcen erwartet und andererseits die komplierten Scriptdateien ablegt.

Ein weiteres Killer-Feature ist das einfache Injizieren von PHP-Variablen in den Javascript-Context, das hier weitestgehend automatisiert abläuft. Interessant in diesem Zusammenhang wäre vielleicht noch zu wissen, in wie weit die I18N-Features des Symfony-Frameworks mit denen der Dojo-Welt verheiratet sind.

Dojo passt also ab Werk bereits hervorragend in jedes Symfony-Projekt, und mit dem sfDojoPlugin lässt sich die Integration nahtlos bewerkstelligen. Hat man sich einmal an die schlechte Dokumentation und die wirklich steile Lernkurve gewöhnt, lässt man mit Dojo meiner Meinung nach in Punkto Stabilität, Funktionsumfang und Projektunterstützung erstmal so ziemlich alles andere hinter sich.

Links

Dojo Toolkit: http://www.dojotoolkit.org/

sfDojoPlugin: http://www.symfony-project.org/plugins/sfDojoPlugin

Eine Beispielimplementierung einer Webbasierten GUI-Komponente für die Build-Tools, leider auf Basis einer veralteten Version : http://build.dojotoolkit.org/0.4.2/web/buildscripts/webbuild/

Ebenfalls veraltet, aber sicher einen Blick wert: GUI für die Dojo Build Tools, Eclipse-basiert: http://shaneosullivan.wordpress.com/2007/01/29/second-beta-of-dojobuilder-released/

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 ?>" />

Alle Änderungen und Verbesserungen sind den Release Notes zu entnehmen. Ich habe direkt mal ein größeres Projekt angehoben, und siehe da – es läuft, von zwei kleinen FehlernEigentoren abgesehen: 1.) Nach dem Update unbedingt den Cache leeren. 2.) Manche Dinge werden jetzt strikter gehandhabt, so kann eine DOJO-Class nicht mehr von einem “undefined” erben. So gibt die Migration Gelegenheit, seinen eigenen Müll zu erkennen und aufzuräumen. Um nicht missverstanden zu werden. Das Update klappte hervorragend, die Probleme resultierten ausschließlich aus der Unfähigkeit des Users ;)

Der erste Eindruck ist ein tatsächlich ein (gefühlter) Geschwindigkeitsvorteil, und vor allem die Dijits/Dojox-Layoutwidgets rendern nun augenscheinlich sauberer. Mein ziemlich aufgebohrtes dojox.grid.DataGrid beispielsweise berücksichtigt nun seine Scrollbalken, auch wenn der unterliegende Datastore “LazyLoad” kann. Das Accordion ist um einiges stabiler geworden – eventuell kann man es nun doch wagen, nach dem Rendern – zur Laufzeit – neue Knoten einzufügen bzw. zu löschen. Der Rest wie gehabt, unglaublich mächtig und leider weiterhin unglaublich schlecht dokumentiert. Aber immerhin:

We’ve not fully resolved the “where the docs live” question, so are providing them as offline static HTML in the downloads section for 1.4.0.

Quelle: http://www.dojotoolkit.org/2009/12/10/new-dojo-release-ready-consumption-1-4-0

Jedenfalls viel Spaß beim Testen, bei aller Malaise ist Dojo meiner Meinung nach weiterhin das ganzheitlichste, quelloffene Javascript-Framework wo gibt.