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.

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();

* 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?

:)

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

[ via ]

Das Tool ermöglicht PHP (debug)Ausgaben direkt an die Firebug Konsole zu schicken:

FB::log('Log message');

FB::info('Info message');

FB::warn('Warn message');

FB::error('Error message');

installieren lässt sich das Ding beqeum via pear:

pear channel-discover pear.firephp.org
pear install firephp/FirePHPCore

einbinden dann so:

// object oriented API
require_once('FirePHPCore/FirePHP.class.php');
$firephp = FirePHP::getInstance(true);
$firephp-> *

require_once('FirePHPCore/fb.php');
FB:: *

dann solche Dinge tun:

$firephp->setEnabled(false);  // or FB::

$firephp->log('Plain Message');     // or FB::
$firephp->info('Info Message');     // or FB::
$firephp->warn('Warn Message');     // or FB::
$firephp->error('Error Message');   // or FB::

auch sehr schön. Logging in Tabellenform:

$table   = array();
$table[] = array('Col 1 Heading','Col 2 Heading');
$table[] = array('Row 1 Col 1','Row 1 Col 2');
$table[] = array('Row 2 Col 1','Row 2 Col 2');
$table[] = array('Row 3 Col 1','Row 3 Col 2');

$firephp->table('Table Label', $table);  // or FB::

fb($table, 'Table Label', FirePHP::TABLE);

oder auch Tracing:

Traces
You can send a backtrace showing File, Line, Class, Method and Function information including Arguments to clearly show the execution path up to the point in your code where you triggered the trace.

$firephp->trace('Trace Label');  // or FB::

fb('Trace Label', FirePHP::TRACE);

uswusw.

uuund:
Es gibt auch ein Symfony Plugin dafür.

1. Daten holen
Die Daten holt man am besten über die Jquery Methode serializeArray().

var s = $('#campaigns form').serializeArray()

Damit holt Jquery alle Values in dieser Form als Array, bei radio oder checkbox types jeweils die aktivierten.

2. Wie versenden?
Nun stellt sich die Frage, wie man die Daten schön aufbereitet und dann versendet.

Man könnte jeden Value manuell als Parameter angeben, ist aber ein wenig umständlich.
Am besten wäre eine Lösung die das Array in ein JSON String wandelt und damit einen Parameter zu füllen:

vars=JSON

Auf dem verarbeitetenden Server kann man den dann wieder decodieren und schön auf key:value pairs arbeiten.

Leider kann Jquery das nicht von Haus aus, dafür braucht es einen JSON stringifier.
Den gibts hier: http://json.org/json2.js (Update: https://github.com/douglascrockford/JSON-js)

Damit gehts dann so:

$.post(url, {module : "saveCampaign",vars : JSON.stringify(s)},function(data){
createActvityDoneDiv_(randomId,data);
})

Auf dem Server decodiert man das dann:

$s = json_decode($_POST['vars']);

…und man bekommt sowas:

[0] = stdClass Object
(
[name] = Name
[value] = asdasdass
)

[1] = stdClass Object
(
[name] = status
[value] = enabled
)

Damit kommt ja schon klar auf dem Server
aber ist doch irgendwie ne scheiss Struktur.
So eine will man haben:

[Name] = asdasdass
[status] = enabled

Da muss der Client wohl noch was arbeiten:

var t = {};
s = $('#campaigns form').serializeArray();
jQuery.each(s,function(){
t[this.name]=this.value;
});
//und ab
$.post(url, {module : "saveCampaign",vars : JSON.stringify(t)},function(data){
createActvityDoneDiv_(randomId,data);
})

Dann gehts.