Mit folgender Konfigurations-Möglichkeiten im User TSconfig lässt sich der Upload im RTE-aktivieren:

options.uploadFieldsInTopOfEB = 1

Und diese Konfigurations-Option erlaubt es dem Benutzer dann sogar noch, auch direkt Ordner anzulegen, um die Uploads besser strukturieren zu können:

options.createFoldersInEB = 1

Sind beide Optionen gesetzt, erscheinen die Upload-Felder direkt im Dateiauswahl-Dialog des RTEs.

Funktionsweise von nc_staticfilecache

Die Extension generiert aus dynamisch erzeugten TYPO3-Seiten – vorausgesetzt, sie enthalten ausschließlich cachebare Elemente – statische HTML-Dokumente als exakte Kopien und legte diese auf dem Webserver ab. Voraussetzung dafür ist die Verwendung einer Extension, die TYPO3 um lesbare Pfade erweitert, wie z.B. realurl oder simulatestatic.

Durch eine Anpassung der mod_rewrite-Konfiguration wird dann bei jeden Seitenaufruf vom Webserver selbst geprüft, ob zu dieser Seite eine statische Variante gespeichert ist. Existiert diese statische Variante, wird diese direkt an den Client ausgeliefert, ohne dass TYPO3 ins Spiel kommt. Es muss kein PHP-Parser gestartet werden, kein TYPO3 geladen werden und keine Datenbankabfrage durchgeführt werden. Laut Eigenbeschreibung der Extension sind dazu Beschleunigungen bis zu 23000% möglich.

Um die Auslieferung von veraltetem Content zu verhindern, werden die statischen Dateien beim löschen des Frontend-Caches mit gelöscht. Darüber hinaus sollte auch noch ein Cron-Job eingerichtet werden, wie im Extension-Handbuch beschrieben. Dieser löscht die statischen HTML-Seiten automatisch nach ihrer definierten Lebensdauer. Diese Lebensdauer entspricht der im Backend eingestellten Cache-Dauer, die zu jeder Seite in den Seiteneigenschaften vorgenommen werden können.

TYPO3-Auftritt mit nc_staticfilecache beschleunigen

Der leichteste Schritt ist die Installation der Extension über den TYPO3-Extension-Manager. Anschließend ist im Modul “Web > Info” der neue Punkt “Statischer HTML Cache” verfügbar. Hier ist ersichtlich, welche Seiten gecached wurden bzw. warum einzelne Seiten nicht gecached wurden.

Die Meldung config.no_cache is true zeigt an, dass die komplette Seite nicht gecached werden kann. Das kann mehrere Gründe haben:

1. Caching in den Seiteneigenschaften deaktiviert
2. Caching im TypoScript deaktiviert (config.no_cache = 1)
3. eine Extension deaktiviert das Caching für diese Seite ($GLOBALS['TSFE']->set_no_cache())

Die Meldung page has INTincScript zeigt an, dass einzelne Elemente nicht gecached werden können. Das können z.B. Plugins sein, die als USER_INT anstatt als USER geladen werden oder TypoScript-Elemente, die vom Typ COA_INT anstatt vom Typ COA sind. Ein Hilfsmittel, um die INT-Elemente ausfindig machen zu können, ist der “TypoScript-Objekt-Browser”, der sich im Modul “Web > Template” einsehen lässt, sobald eine Seite im Seitenbaum ausgewählt wurde.
Ist ein INT-Objekt ausfindig gemacht, gilt es zu überlegen, ob sich das Caching für dieses Element nicht evtl. doch erlauben lässt. Ist dies der Fall, kann der Typ via TypoScript geändert werden:

	# noncacheable INT objects
plugin.user_myextension = USER_INT
lib.mytyposcriptobject = COA_INT

	# cacheable objects
plugin.user_myextension = USER
lib.mytyposcriptobject = COA

Nachdem die Extension installiert ist, und die Seiten als statische Kopien auf dem Webserver abgelegt werden, muss noch die mod_rewrite-Konfiguration angepasst werden. Eine Beispiel-Konfiguration dazu befindet sich in Extension-Handbuch. Diese muss aber je nach Serverumgebung und realurl- bzw. simulatestatic-Konfiguration noch angepasst werden.

Fazit

Durch einen geschickten Einsatz der Extension “nc_staticfilecache” lässt sich der TYPO3-Auftritt extrem beschleunigen und die Serverlast deutlich reduzieren. Voraussetzung dafür ist jedoch ein durchdachter Einsatz von nicht-cachebaren INT-Elementen, die es zu vermeiden gilt. Schließlich kann ein einziges Plugin, das nicht gecached werden darf, schon den kompletten Einsatz der Extension verhindern.

Die Extension “nc_staticfilecache” ist in ihrer aktuellsten Version über das Extension Repository erhältlich.

Umgehen lässt sich dies mit Hilfe der der extract() Methode der Sound-Klasse. Hier wird das gesamte Frequenzspektum des Sounds augelesen und kann weiter verwendet werden. Aber es gibt einen gravierenden Unterschied bei beiden Mehtoden. Die computeSpectrum liefert von Haus aus eine schnelle Fourier Transformation mit. Hingegen liefert die extract()-Methode nur RAW-Daten zurück. Kurz zusammengefasst bedeutet dies, dass mit Hilfe der computeSpectrum die zurückgelieferten Frequenzen nach Bereich sortiert werden und bei der anderen Funktion eben nicht.

Klar könnte man hingehen und selbst eine einfache Sortierfunktion schreiben. Doch bei der etwas größeren Datenmenge die bewältigt werden muss, wird dies das Script auf jeden Fall verlangsamen. Eine Methode die verwendet werden kann zur Sortierung ist die Schnelle Fourier-Transformation, die auf der Diskreten Fourier-Transformation basiert. Aber leider gab es diese Funktion, wie gesagt, nur innerhalb der computeSepctrum() Methode.

Nun hat Eugene Zatepyakin sich die Mühe gemacht und eine Implementierung der schnellen Fourier-Transformation in ActionScript 3 geschrieben, die frei verfügbar bei Google-Code ist. Mit Hilfe dieser Klassen konnte ich, nach ein paar Tests, den SoundVisualizer mit der Funktionalität zur Sortierung der Sound Daten erweitern, ohne die oben kurz angerissenen Probleme wieder aufzureißen.

Die Implementierung ist, wie Eugene sie auch beschreibt, sehr einfach. Für die Verwendung mit Sound wird die FFT-Klasse verwendet. Des weiteren gibt es noch die FFT2D-Klasse, welche die Möglichkeit eine zweidimensionale Transforation durchzuführen bietet, wie sie etwa bei Bildern Verwendung findet. Bei der Initialisierung der Klasse mit deren init()-Methode sollte man auch nicht über 2048 Bytes gehen, da sonst wiederum die Performance leidet. Besonders ist darauf zu achten, dass die Anzahl der ausgelesenen Bytes über die extract-Methode mit der bei der init Methode übereinstimmt.

Der eingentliche Analyzer ist in der FFTSpectrumAnalyzer-Klasse. Hier wird in der initLogarithmicAverages-Methode zunächst die Mindestbandbreite angegeben und die Anzahl an Bändern, in die eine Oktave unterteilt werden soll.
Sehr wichtig ist auch die Einstellung “Little Endian” für den ByteArray, welcher die resultierenden Daten hält. Innerhalb des onSampleDataEvent-Handlers werden die ausgelesenen Bytes dann der fft-Klass mittels setStereoRAWDataByteArray(bytes) mitgegeben, um dann anschließend die forwardFFT() aufzurufen, welche die eigentliche Transformation ausführt. fftHelp.analyzeSpectrum() liefert dann den analysierten ByteArray, welcher dann weiter benutzt werden kann für alle möglichen visuellen Ausgaben, zurück. Noch ist hier der Sound selbst noch nicht ausgegeben. Dafür müssen die Bytes zurück transformiert werden über fft.inverseFFT(). Nach dem Zurücksetzen der Position innerhalb des BytesArrays können nun die SoundBytes an event.data zur Ausgabe übergeben werden. Den genauen Ablauf der Funktionen kann man auch auf Google Code nachlesen. Hier hat Eugene zwei Beispielscripts eingefügt. Und als anschauliches Beispiel für die Verwendung seiner Bibliothek einfach den zeroseven SoundVisualizer anschauen. Hier ist im letzten Reiter eine weitere Checkbox, in der man angeben kann, ob die Daten sortiert (FFT) oder unsortiert (RAW) verwendet werden sollen.

Links:

• Vergleich computeSpectrum und extract: http://labs.zeroseven.de/development/actionscript-development/soundmixer-computespectrum-vs-sound-extract-2/
• Wikipediaeintrag zur Schnellen Fourier-Transformation: http://de.wikipedia.org/wiki/Schnelle_Fourier-Transformation
• Wikipediaeintrag zur Diskreten Fourier-Transformation: http://de.wikipedia.org/wiki/Diskrete_Fourier-Transformation
• Eugenes Blog zu ASFFT: http://blog.inspirit.ru/?p=405
• Eugenes Blog zu Update von ASFFT: http://blog.inspirit.ru/?p=410
• Google Code Seite: http://code.google.com/p/in-spirit/wiki/ASFFT
• Beispiel zur Verwendung von ASFFT: http://visualizer.zeroseven.de

Native Installers
AIR Applikationen können nicht nur als *.air Dateien exportiert und weitergegeben werden, sondern auch als “Native Installer” also *.exe für Windows bzw. *.dmg für MacOS. Dies ist die Voraussetzung um mit Systemprozessen kommunizieren zu können. Ein weiterer Vorteil von Native Installers ist, dass die AIR Runtime mit der Applikation installiert wird, falls diese noch nicht auf dem System des Benutzers verfügbar ist und eine Internetverbindung besteht. Falls der Benutzer nicht mir dem Internet verbunden ist, kommt wenigstens eine Meldung man solle sich doch bitte die aktuelle AIR runtime von der Adobe Seite herunterladen. Weiterhin gibt es die Möglichkeit die AIR Runtime zum Beispiel auf einer CD/DVD mitzuliefern, dafür ist allerdings eine Re-Destributable Lizenz von Adobe nötig, siehe Blogeintrag von Mike Chambers.

Erstellen eines Native Installers
Da man aus FlashBuilder standardmäßig nur *.air Files exportieren kann müssen hier auf die Konsole zurückgreifen. Das Packagingprogramm hierfür heißt ADT und befindet sich im bin Ordner des AIR sdks. Es gibt grundsätzlich zwei verschiedene Arten Native Installers zu erstellen:

• aus dem Sourcecode eines AIR Projekts
• aus einer bereits bestehenden AIR Datei

Dieser Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus den Quelldaten der Applikation.

adt -package -storetype pkcs12 -keystore myCert.pfx -target native myApp.dmg main-app.xml main.swf

Folgender Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus einer AIR Datei

adt -package -target native myApp.dmg myApp.air

Um einen Native Installer für Windows zu erstellen wird einfach anstatt myApp.dmg myApp.exe verwendet. Einschränkung: Native Installers können immer nur für das Betriebssystem erstellt werden das gerade genutzt wird. Will mal also ein *.exe für Windows erstellen muss ADT unter Windows aufgerufen werden.

Mehr Infos dazu auf der Adobe Hilfe.

NativeProcess API
Die NativeProcess Klasse bietet die Möglichkeit mit einem Systemprozess zu interagieren. Über die Funktionen start(info:NativeProcessStartupInfo):void und exit(force:Boolean = false):void werden Prozesse gestartet und beendet. Über die Eigenschaften running, standardError, standardInput und standardOutput kann der Prozess überwacht werden.

Der Funktion start() wird eine NativeProcessStartupInfo Objekt übergeben das Informationen zum Prozess enthält der gestartet werden soll. Die Eigenschaft executable muss eine Referenz auf die Datei enthalten die gestartet werden soll und über arguments kann eine Vector von Strings
mit Parametern angegeben werden.

var file = new File('/Applications/Firefox.app/Contents/MacOS/firefox-bin');
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.executable = file;
var process:NativeProcess = new NativeProcess();
process.start(nativeProcessStartupInfo);

Dies ist nur ein kleines Beispiel das natürlich beliebig erweiter werden kann. Schön ist auf jeden Fall, dass sich dadurch ganz neue Möglichkeiten für AIR Applikationen auftun. Der große Nachteil von AIR bleibt aber weiterhin, dass die AIR Runtime auf jeden Fall installiert werden muss, es ist also zum Beispiel kein Starten von CD möglich.

Links und weitere Beispiele:

• Adobe DevNet: Interacting with a native process
• Adobe Help: Packaging an AIR application in a native installer
• Mike Chambers: Redistributing the Adobe AIR Runtime Installer
• Adobe: Distribute Adobe® AIR® Runtime

Die PHP-Konstante USER_POSITION wird vom Adminbereich auf den Wert admin gesetzt und vom Shop auf den Wert store. Sollen also Aktionen entweder nur im Shop oder nur im Adminbereich ausgeführt werden, lässt sich das mit einer einfachen if-Anweisung regeln.

if(USER_POSITION == 'admin') {
	// do some action
}

if(USER_POSITION == 'store') {
	// do some action
}

AJAX mit eID-Machanismus

Mit dem integrierten eID-Mechanismus von TYPO3 ist es möglich, eigene PHP-Scripte ohne großen Overhead aufzurufen. Instanziert wird dabei nur alles, was man unbedingt braucht oder will. Der Nachteil dabei ist jedoch, das viele interne TYPO3-Bordmittel nicht zur Verfügung stehen. So müssen z.B. für die Spracherkennung oder wenn TypoScript-Bedingungen beachtet werden sollen, komplizierte Workarounds integriert werden. Dadurch wird das anfänglich schlanke Script schnell aufgebläht und unübersichtlich. Und im schlimmsten Fall entstehen dadurch sogar Sicherheitslücken, beispielsweise dann wenn es dem Benutzer Möglich ist, über das AJAX-Backends Daten abzufragen für die er in seiner Benutzergruppe ggf. gar keine Berechtigung haben sollte.
Der eID-Mechanismus ist also meiner Meinung nach für einfache und unkomplizierte Abfragen geeignet. Kommen aber irgendwelche Bedingungen ins Spiel, von denen die Abfrage abhängig sein sollte, empfehle ich eine andere Herangehensweise.

AJAX mit eigenem Seiten-Typ

Wer schon einmal ein TYPO3-Projekt erstellt hat, kennt die Seiten-Typen vermutlich von der Druckansicht. Oftmals wird mit typeNum=98 ein Page-Objekt für die Druckansicht definiert, dass sich dann mit einem angehängten Parameter (z.B. http://www.example.com/index.php?id=1&type=98) aufrufen lässt und eine völlig andere Ansicht der Webseite offenbart.
Genau dieses Feature lässt sich auch nutzen, um ein z.B. ein eigenes Extension-Plugin mit einem definierten Seiten-Typ zu verknüpfen. Hier im Beispiel erzeugen wir mit myajax ein neues Objekt vom Typ PAGE. Mit typeNum = 789 wird dann eine alternative Typ-Nummer vergeben. Und nach ein paar Beispielkonfigurationen wird dann noch das Plugin als einziger Content eingebunden.

Unser Plugin ist dann direkt über http://www.example.de/index.php?id=23&L=1&type=789 erreichbar und liefert automatisch die korrekten Ergebnisse, abhänig vom gesetzten Sprachparameter, der gewählten Seite und den aktuellen Berechtigungen des Benutzers. (Die Parameter id und L im Beispiellink sind natürlich variabel und hier nur als Beispiel gesetzt.)

	# prepare alternative page type
myajax = PAGE
myajax.typeNum = 789
myajax.config {
	disableAllHeaderCode = 1
	additionalHeaders = Cache-Control: no-cache, must-revalidate, max-age=0|Expires: Mon, 2 Jan 2006 01:00:00 GMT|Pragma: no-cache
	xhtml_cleaning = 0
}
	# register plugin directly as page content
myajax.10 < plugin.user_myajaxplugin_pi1

Der Nachteil dieser Lösung ist, dass bei jeder Anfrage der komplette standardmäßige TYPO3-Overhead mitgeführt wird. Es ist also von Haus aus eher die etwas langsamere Variante im Vergleich zur oben genannten eID-Lösung.

Der enorme Vorteil hingegen ist jedoch, dass sich die AJAX-Serverfunktionalität exakt gleich zur normalen Seite verhält. Alle Spracheinstellungen, die Berechtigungen für irgendwelche Seiten, TypoScript-Conditions, etc. haben auch direkten Einfluss auf die AJAX-Funktionalität und können von einem Angreifer nicht mit einfachen Parameter-Änderungen in der Adresse ausgehebelt werden.

Fazit

Grundsätzlich würde ich keine der beiden Varianten als “besser” oder “schlechter” bezeichnen. Für einfache AJAX-Abfragen ohne Einschränkungen wie z.B. Sprache, Berechtigung, etc. würde ich die kleinere Schlankere Variante mit dem eID-Mechanismus wählen. Sobald aber Inhalte nur für eine bestimmte Besuchergruppe sichtbar sein sollen, oder in verschiedenen Sprachen verfügbar, rate ich zweifellos zur Variante mit dem eigenen Seiten-Typ.

Um es gleich Vorweg zu nehmen: Es war der Hammer. Die Fülle an Eindrücken, von neuen Ideen, Technologien und Ansätzen war wieder immens und macht wiederum klar wie mächtig eigentlich die Flash Platform ist. Aber auch die Selbstverständlichkeit im fast schon familiären Umgang der Coder untereinander war wieder beindruckend. Wann hat man denn schon die Möglichkeit die “Größen” der Szene zu treffen und mit ihnen alltägliche Coderprobleme zu besprechen.

Dieser Text soll nun nur einen kleine Überblick sein, was ich an Themen mitbekommen hab in den Vorträgen. Ich denke in der nächsten Zeit werden Jürgen und ich immer mal wieder ein Thema hier von auf diesem Blog behandeln. Serge Jespers eröffnete die FFK und stellte unter anderem die Flash Platform Services vor. Interessant hier vor allem die Bereiche Distribution und Collaboration. Die ebenfalls dazugehörenden Social Services waren schon aus dem com.adobe Package bekannt.

Ich möchte jetzt nicht auf jeden Vortrag eingehen den ich gesehen habe. Aber ein paar Highlights für mich herauspicken. Dazu zählt unter anderm der Vortag von Michael Wacker “Mind the gaps”, der das Themas Flash Security hatte. Eine richtig gute Anregung und ein Fingerzeig für die Community, was es noch mangelt. Ganz klar mit dabei bei meinen Favoriten mit dabei Andre Michelles “Tanzen mit Krücken”. Sehr beeindruckend, vor allem interessant, dass immer mal wieder Tipps und Trick durchsickerten, wie SWFs schnelle und sicherer Laufen. Aber dies nicht nur bei ihm. Auch Saban Ünlü oder Ralph Hauwert mit seinen experimentellen Animationen, ließen hier und da immer wieder ein paar Worte dazu fallen.

Aber auch Bereiche wie Performance Tuning, Usability Testing, Aufbau von Software für Multitouch Devices waren Themen auf der FFK. Richtig beeindruckend, wie schon letztes Jahr, die beiden Vorträge von Joa Ebert und Mario Klingemann. Joas “Apparat” ist kurz gesagt einfach der Hammer. SWF ByteCode Optimierung um so noch mehr auf Flash rauszuholen und noch schnelle Animationen laufen lassen zu können. Der experimentelle und künstlerische Ansatz von Mario versetzt jeden Flasher immer wieder in Staunen.

Der für mich am interessanteste Vortrag war aber von Jens Halm: “Enterprise Applications mit dem Parsley Application Framework”. Ich hatte davor wenig gehört von Inversion of Control und der ganzen Thematik die hier vorgestellt wurde. Aber der Ansatz der Modularisierung des Codes und der Vereinfachung der Zugriffe und Abhängigkeiten, vor allem die Implementierung in Cairngorm 3 haben mich hellhörig gemacht. Ein Ansatz der Programmierung der mir sehr entgegen kommt und vor allem auch den Workflow des einzelnen und eines ganzen Teams, aber auch das Testen von Apps und Teilbereiche deren immens vereinfacht und verbessert.

Ich könnte jetzt so noch ewig weiter schreiben, da beide Tage voll solche Eindrücke waren. Aber wie gesagt, in nächster Zeit gibt es hier immer wieder ein paar Auszüge davon. Nur eins noch: Ich warte jetzt schon auf die FFK 2011!

http://ffk10.flashforum.de/
http://www.adobe.com/flashplatform/services/

In den Seiteneigenschaften verbirgt sich unter dem Reiter “Optionen” die kleine unscheinbare Checkbox “Ist Anfang der Web-Site” (engl.: “Is root of website“). Diese Checkbox muss auf der Root-Page wirklich gesetzt sein – und natürlich die Root-Page auch in der realurl-Konfigurationsdatei korrekt gesetzt sein – uns schon klappt der Seitenübergreifende Link auch wunderschön mit realurl.

Tipp: Wenn Ihr die Checkbox “Ist Anfang der Web-Site” nicht sehen könnt, blendet einfach die zweite Optionspalette ein.

Die Lösung liegt in der Tabelle, die intern über die Konstante TABLE_ADMIN_NAVIGATION angesprochen wird. Vermutlich heißt diese Tabelle bei Euch xt_acl_nav oder acl_nav. Wenn nicht, könnt Ihr sie auf jeden Fall über die interne Konstante herausfinden. Bitte beachtet außerdem, dass die Reihenfolge, wie ich auf die Felder eingehen werde, nicht der Reihenfolge in der Datenbank entspricht, sondern für ein besseres Verständnis angepasst wurde.

text
Die eindeutige Bezeichnung des Navigationspunktes. Der Text kann dann selbstverständlich über die Lokalisierungstabelle an die jeweilige Sprache des Admin-Benutzers angepasst werden.

icon
Zu jedem Navigationspunkt gibt es neben dem Text auch das kleine Icon. Der Pfad muss relativ zum Verzeichnis xtAdmin sein und die Grafik sollte 16×16 Pixel groß sein.

navtype
Gibt an, in welche Navigation der neue Punkt integriert werden soll. Mögliche Werte sind N und W. Vermutlich steht das für “North” und “West”. Denn schließlich kann man mit N einen Button in der oberen Navigationsleiste neben “Handbuch”, “Helpdesk”, etc. ablegen, während man mit W einen Navigationspunkt in der linken Hauptnavigation erzeugt.

type
Wenn navtype=W angegeben wurde, kann der Typ auf den Wert G oder I gesetzt werden. G enthält weitere Unterpunkte und könnte von “Group” abgeleitet worden sein. I enthält keine weitere Unterpunkte, sondern ist selbst der letzte Unterpunkt einer Gruppe, die Bezeichnung könnte von “inner” abgeleitet worden sein.
Für navtype=N muss der Wert G eingetragen werden.

parent
Für navtype=W zeigt das Feld an, welchem Elternelement der Navigationspunkt zugeordnet worden sein. Das Elternelement muss vom type=G sein. Wird hier der Wert 0 eingetragen, wird in der Navigation ein komplett neuer Block angelegt. Um das neue Navigationselement in eine vorhandene Gruppe einzugliedern, muss deren bei text eingetragene Bezeichnung hier hinterlegt werden.
Für navtype=N muss der Wert 0 eingetragen werden.

sortorder
Ein einfacher Sortierungswert als Integer. Niedrige Werte werden zuerst dargestellt, höhere Werte danach.

Mit einem kleinen Eingriff in die .htaccess-Datei lässt sich der SWF-Uploader aber auch zum Laufen bringen, ohne den Passwort-Schutz vom ganzen Projekt zu nehmen. Dazu müssen einfach folgende Zeilen in die .htaccess-Datei eingefügt werden.

<Files ajax.php>
Allow from any
Satisfy any
</Files>

Die erste und vierte Zeile bewirken, dass die Anweisung nur für Dateien mit dem Namen ajax.php gelten soll. Zeile 2 besagt, dass ein Zugriff von jeder IP-Adresse aus möglich ist und Zeile 3 bewirkt, dass entweder die User-Authentifizierung via Passwort oder die IP-Adresse des Besuchers stimmen muss. Und da der Besucher jede beliebige IP-Adresse besitzen darf (Zeile 2), ist die Zugriffsbeschränkung für die Datei ajax.php aufgehoben und der SWF-Uploader funktioniert wieder tadellos.