In the last days, i was trying to find a solution hosting multiple Express apps on my vServer the same Server.

Starting with Apache and mod_proxy, i ended up with a plain node solution, which i really like.

Let’s take a quick look on some different approaches out there:

—1—

Using apache on port 80 as a proxy

ProxyPass /nodeurls/ http://localhost:9000/
ProxyPassReverse /nodeurls/ http://localhost:9000/

via stackoverflow

– no websockets
++ probably the easiest way to integrate with your running AMPP-stack

—2—

Using a node.js app on port 80 as a Wrapper for other node apps.

express.createServer()
  .use(express.vhost('hostname1.com', require('/path/to/hostname1').app)
  .use(express.vhost('hostname2.com', require('/path/to/hostname2').app)
.listen(80)

via stackoverflow

++ you can use websockets on port 80
– apps crash/restart/stop globally
–what about your apache or the like?

—3—

Using node.js with node-http-proxy on port 80

var http = require('http')
, httpProxy = require('http-proxy');

httpProxy.createServer({
  hostnameOnly: true,
  router: {
    //web-development.cc
    'www.my-domain.com': '127.0.0.1:3001',
    'www.my-other-domain.de' : '127.0.0.1:3002'
  }
}).listen(80);

++ proxy websockets to any port
– you might need to move your old web server to another port

The really cool thing about using node-http-proxy is its capability of proxying websockets.
So you can have your apps running independtly on different ports while serving everything to the user over port 80 and use stuff like socket.io.

Since i’m new to node.js and miles away from beeing a admin, any feedback is highly appreciated :)

…for some reason i needed to get t h i s to work before going to sleep.

I’m running OSX 10.7.3 with macports which usually does the job, but  Google’s V8 Javascript Engine is not available as a port yet.

So… homebrew to the rescue:

installed it:

/usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/gist/323731)"

and installed v8

brew install v8

wait, this seems too easy.

PECL installed some beta version of the PHP extension.

sudo pecl install channel://pecl.php.net/v8js-0.1.2

added

extension=v8js.so

to the php.ini file.

und bitteschön:

$v8 = new V8Js();
var_dump($v8->executeString("

//hey i'm Javascript Code

//INSIDE PHP !

//wow.
var hello = 'Hallo';

function helloWorld( string ){
return hello + ' ' + string;
}

helloWorld('World');

"));

Such things might come in handy one day, you know.

Hier mal eine anfänglich kleine Sammlung zum Thema HTML 5 generell – grob kategorisiert. Vervollständigungen und Streichungen willkommen.

Cross Browser Helper

Html 5 Validator (en)

http://html5.validator.nu/

Html5 Browser capability test (en)

http://html5test.com/

Html readyness – fancy browser comparison (en)

http://html5readiness.com/

Modernizr – Cross-Browser Html5 & CSS3 Support (en)

http://www.modernizr.com/

Html5Shiv – Html5 for IE (en)

http://code.google.com/p/html5shiv/

IE-7 js – Standard complient IE 7 (en)

http://code.google.com/p/ie7-js/

Html 5 CSS-Reset (en)

http://html5reset.org/
http://html5doctor.com/html-5-reset-stylesheet/

HTML 5 Boilerplate – Best Practices, Scripts und Server-Konfigurationen

http://html5boilerplate.com/ (en)
http://de.html5boilerplate.com/ (de)

Audio/Video

Html 5 Audio and Video – What you must know (en)

http://net.tutsplus.com/tutorials/html-css-techniques/html5-audio-and-video-what-you-must-know/

Video accessiblity (en)

http://wearehugh.com/public/2010/08/html5-video-accessibility/Your text to link…

Canvas

Canvas cheat sheet (en)

http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html

Reference Guide (de)

http://canvas.quaese.de/

Canvas beginners guides (en)

http://www.brighthub.com/internet/web-development/articles/38744.aspx
http://www.visitmix.com/Articles/Translating-CANVAS-with-HTML5

Canvas demos & tutorials (en)

http://www.canvasdemos.com/

Cookbooks & Tutorials

WHATWG Weblog (en)

http://blog.whatwg.org/

Html 5 laboratory (en)

http://www.html5laboratory.com/

Dive into Html 5 (en)

http://diveintohtml5.org/

Html5 Playground (en)

http://www.html5rocks.com/

Tag reference (en)

http://www.w3schools.com/html5/html5_reference.asp

Fancy tag reference (en)

http://joshduck.com/periodic-table.html

Html5 Techniques – Ultimate collection of tutorials (en)

http://www.tutoriallounge.com/2010/11/html5-techniques-ultimate-collection-of-tutorials/

Useful html 5 code snippets (en)

http://www.onextrapixel.com/2010/11/15/useful-html5-code-snippets-you-can-use-today/

Geolocation using the Google API (en)

http://papermashup.com/html5-geo-location-using-the-google-api/

Fun with html5 forms

http://thinkvitamin.com/code/fun-with-html5-forms/

Blog-Artikel & andere Quellen

Webkrauts Artikel zum Thema (de)

http://www.webkrauts.de/category/html5-einfuehrung/

What beautiful Html5 code looks like (en)

http://css-tricks.com/what-beautiful-html-code-looks-like/

48 Flash killing HTML 5 demos (en)

http://www.hongkiat.com/blog/48-excellent-html5-demos/

HTML 5 facts & myths (en)

http://www.smashingmagazine.com/2010/09/23/html5-the-facts-and-the-myths/

Learning to love html 5 (en)

http://www.smashingmagazine.com/2010/11/10/learning-to-love-html5/

Designing a html 5 layout from scratch (en)

http://www.smashingmagazine.com/2009/08/04/designing-a-html-5-layout-from-scratch/

Push-Mechanismen im Web sind mittlerweile weit verbreitet – die Anforderungen an die Infrastruktur aber recht hoch. Nichts geht ohne Plugins (Flash, Applet, WebSocket) – dann braucht man mindestens einen zweiten Server, der via persistenter Verbindung Nachrichten verteilt.

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

Exceptionhub protokolliert clientseitig auftretende Javascript Fehler.

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

:)

pushing the boundaries

um den ZoomFaktor auf GoogleMaps dynamisch zu setzen,
je nachdem wie viele Marker man wo hat, kann man GLatLngBounds benutzen.

var bounds = new GLatLngBounds();

Mit jedem Marker der dazukommt erweitert man dann einfach die Grenzen:

bounds.extend( myGLatLng );

und schon kann man komfortabel Zoom und Center-Punkt rausbekommen.
So das alle Marker sichtbar sind.

map.setCenter ( bounds.getCenter(), map.getBoundsZoomLevel(bounds) );

die jQuery UI ist jetzt in Version 1.8 erschienen.

neben einer optimierten Codebasis

jQuery UI Core 71% smaller

gibt es auch wieder ein paar neue Widgets.

Wie z.B. das position widget, das ausgefallenere Positionierungs-Spielereien erlaubt:

“linke obere Ecke von diesem Element -20px 10px von der rechten unteren Ecke von $(‘#parent’) positionieren.”

function position() {
  $('#positionable').position({
    my: 'left top',
    at: 'right bottom',
    of: $('#parent'),
    offset: '-20 10'
  });
}

Kann man dann natürlich auch an Events hängen:

$("#parent").draggable({
  drag: function() { position(); }
});

Auch ein Autocomplete-Widget ist jetzt dabei (endlich !:)
sieht auch gut aus auf den ersten Blick.

Das Dojo Toolkit bietet neben den offensichtlichen Features eines Full-Stack-Frameworks unter anderem mehrere “environment aware” Debug-Modi und eine Sammlung vonBuild-Scripten, die es dem Entwickler erlauben, das Framework zusammen mit den eigenen Frontend-Scripten und Stylesheets zu “kompilieren” und somit Bandbreite zu sparen bzw. Ladezeiten zu minimieren.

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/

Juitter ist ein Twitter Widget basierend auf jQuery. Damit kann man Twitter nach gewissen Keywords durchsuchen und die Anzeige als Widget mit wenig Code auf seiner Seite einbinden. Das alles ist rein clientseitig, was es noch einfacher macht.

Das geht so:
Juitter (1.0) runterladen, in sein Projekt kopieren.

Javascript einbinden:

<script language="javascript" src="/app/js/jquery-1.3.1.min.js" type="text/javascript"></script>
<script language="javascript" src="/app/js/jquery.juitter.js" type="text/javascript"></script>
<script language="javascript" src="/app/js/system.js" type="text/javascript"></script>

Container in die Seite einbinden:

<div id="juitterContainer"></div>

CSS einfügen:

#juitterContainer { overflow: auto; padding: 2px; font-size: 12px; height: 650px; width: 419px; border: 1px solid silver }
/*JUITTER PLUGIN CSS*/
#juitterContainer .twittList{margin:0;padding:0;} /* UL that will contain the list of tweets */
/* Bellow the list of tweets "<li>" */
#juitterContainer .twittLI{list-style:none;background:#EEFDEA;margin:0;padding:5px 0 0 0;border-bottom:dashed 1px #CAF8C9;padding:3px;clear:both;height:55px;}
#juitterContainer .twittList SPAN.time{color:#777;font-size:0.9em}
#juitterContainer .twittList A{color:#006600;} /*Links inside the tweets list */
/* Bellow the CSS for the avatar image */
#juitterContainer .juitterAvatar{float:left;border:solid 1px #D3EECA;background:#FFF;margin-right:5px;padding:2px;width:48px;;height:48px;}
#juitterContainer .jRM{float:right;clear:both} /*read it on twitter link*/
#juitterContainer .extLink{} /*CSS for the external links*/
#juitterContainer .hashLink{} /*CSS for the hash links
*/ /*end of Juitter CSS*/

und fertig!

Die Konfiguration geht in der system.js.
Dort kann man die zu suchenden Keywords einstellen, die Update Intervalle und noch einiges mehr.

Was noch etwas verbesserungswürdig ist, ist die Datumsanzeige, hier nimmt Juitter ganz einfach das von Twitter übergebene RFC 2822 Datum und stellt es dar.

Das geht auch schöner!
Dazu hab ich das jQuery PrettyDate Plugin genommen und mit Juitter gebündelt.
Also Plugin noch einbinden:

<script language="javascript" src="/app/js/jquery.prettydate.js" type="text/javascript"></script>

Dann Juitter ein wenig aufgebohrt, so dass man nun in der system.js eine dateFormat option hat:

//set your Date Format:
//locale: uses JS toLocaleString
//pretty: uses prettyformat like so: 3 Days ago
//normal: RFC 2822 formatted date

dateFormat: "pretty"

Sprach Einstellungen für prettyDate sind auch möglich:

$.prettyDate.messages = {
now : "gerade eben",
minute : "vor einer Minute",
minutes : $.prettyDate.template("vor {0} Minuten"),
hour : "vor einer Stunde",
hours : $.prettyDate.template("vor {0} Stunden"),
yesterday : "Gestern", days : $.prettyDate.template("vor {0} Tagen"),
weeks : $.prettyDate.template("vor {0} Wochen")

}

Und schon ist es ein bißchen schicker!
Den Bundle gibts hier (juitter.dateimproved) zum download.
Alles weitgehend ungetested und ohne Gewähr.
Bleibt zu hoffen, dass es in die nächste Juitter Version integriert wird.

Um eine HTML Textarea mit Code Highlighting zu versehen muss man ein bißchen tricksen.
Zum Glück gibts ja da schon fertige Libs, die das erledigen.
Sucht man mit Google, findet man schnell dieses hier:

http://codepress.sourceforge.net/
Dies wird aber scheinbar nicht weiterentwickelt und hat zudem einige Bugs.

Weiterhin gibts dann http://sourcepad.org.
Das sieht ganz gut aus, für meine Zwecke schon zu gut, daher habe ich mich für dieses entschieden:
http://marijn.haverbeke.nl/codemirror

Also der CodeMirror:
Installation ist einfach:
Runterladen, die nötigen Files einbinden:

<script type="text/javascript" src="js/codemirror.js"></script>
<link rel="stylesheet" type="text/css" href="css/docs.css">

Den linenumber style setzen (warum das nicht in der docs.css schon drin, fragt man sich?)

<style type="text/css">
      .CodeMirror-line-numbers {
        width: 2.2em;
        color: #aaa;
        background-color: #eee;
        text-align: right;
        padding-right: .3em;
        font-size: 10pt;
        font-family: monospace;
        padding-top: .4em;
      }
</style>

Eine Textarea anlegen:

<textarea id="code" name="PAGE_CONTENT"></textarea>

und das Highlighting aktivieren:

    var editor = CodeMirror.fromTextArea('code', {
    height: "350px",
    width: "700px",
    parserfile: "parsexml.js",
    stylesheet: "css/xmlcolors.css",
    path: "js/",
    continuousScanning: 500,
    lineNumbers: true
  });

Das wars schon.
Die Konfigurationsmöglichkeiten werden im Manual ganz gut erklärt, da gibts dann weitere Infos.

Spannend wirds allerdings wenn nun die Form submitted werden soll um den geänderten Code zu verarbeiten.
Denn der Trick bei dieser, wie auch bei den anderen Libs ist, dass das die Textarea unsichtbar gemacht wird und stattdessen ein iFrame gerendert wird mit dem Highlighting.

Submitted man nun die Form, wird natürlich nicht der aktuelle Inhalt übertragen sondern unverändert der alte.
Um zu erreichen, dass der neue Inhalt übertragen wird, muss man vorher den Code aus dem iFrame holen und in die ursprungliche Textarea setzen.
Daher besser keinen Submit Button benutzen, da ein Submit direkt feuert.
Besser ein onclick auf einen normalen Button und eine javascript funktion zwischenschalten die den Transfer übernimmt und danach submittet.
CodeMirror bietet dafür, sehr praktisch, eine Funktion an, die einem den geänderten Code liefert: getCode()
Als prototype event sehe das dann so aus:

//button id=save
Event.observe('save','click',function(event) {
 	 	  $('code').value = editor.getCode();
		  $('form').submit();//die form mit id = form
});

So siehts aus:

coole sache!