<s:MobileApplication>
 
....
 
</s:MobileApplication>

MobileApplication wurde umbenannt in

 
<s:ViewNavigatorApplication>
 
....
 
</s:ViewNavigatorApplication>

autoOrientation aus

Sucht in der app-Xml die Zeile

<autoOrients>true</autoOrients>

und setzt diese auf false.

<autoOrients>false</autoOrients>

Diese Anweisung sorgt dafür, dass sich die Applikation nicht mehr am Beschleunigungssensor orientiert und die erste View eurer App wird nach den Einstellungen in der Zeile

<aspectRatio>landscape</aspectRatio>

ausgerichtet.

<aspectRatio>landscape</aspectRatio>

steht, falls diese Zeile bei euch nicht vorhanden sein sollte, zwischen

<initialWindow>
...
...
<aspectRatio>landscape</aspectRatio>
</initialWindow>

Manuelle Steuerung der Orientierung

Um nun der View manuell die Orientierung zu übergeben, sprecht ihr das viewActivate-Ereignis in eurer View an. Dies macht ihr in der View-Deklaration euere View-MXML. Dort platziert ihr eine Funktion, um das Ereignis abzufangen.

<s:View xmlns:fx="http://ns.adobe.com/mxml/2009" 
		xmlns:s="library://ns.adobe.com/flex/spark" title="Your title" viewActivate="onActive(event)">

Innerhalb dieser Funktion könnt ihr nun die Orientierung vorgeben.

public function onActive(e:Event):void 
{
stage.setAspectRatio(StageAspectRatio.PORTRAIT);
}

Hier könnt ihr entweder StageAspectRatio.PORTRAIT oder StageAspectRatio.LANDSCAPE nutzen. Dies ist der Weg, der nicht zu einer deprecated Warnung im Compiler führt und deshalb wohl der vernünftigere Weg. Den anderen Weg findet ihr hier http://cookbooks.adobe.com/post_Auto_orient_your_mobile_application_to_the_device-18224.html.

Ich hoffe, dass spart euch ein wenig Zeit.

http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/package-detail.html

Vielleicht ist der Link für den einen oder anderen ja nützlich.

Usability? Kenn ich.

Benutzerfreundlichkeit als Dienste am Nutzer ist nunmehr nichts mehr Neues. Nachdem 2002 Steve Krug mit “Don’t make me think” schon mal einen Denkanstoß für Website Konzeptioner gegeben hatte, ist Benutzerfreundlichkeit von Websites wohl das Schlagwort seit 2008.
Firmen und Agenturen, die es sich leisten können, bringen ihre Webseiten und/oder mobile Applikation zu Usability-Agenturem und lassen testen, ob der DAU auch verstanden hat, was er zu tun hat. Dies ist zunächste auch nichts schlechtes und der gewünschte Erfolg (mehr Umsatz, Registrierungen, Kundenbindung, Gewinn, Stärkung der Marke etc.) stellt sich meist tatsächlich ein. Ganz nach Krug: “Wenn es einfach zu benutzen ist, benutze ich es auch öfter”.

Benutzerfreundlichkeit beginnt im Backend

Doch ist es auch erfolgsentscheidend für die Website, ob die Pflegearbeit im Backend, die der Redakteur oder der Kunde selbst betreibt, einfach zu handhaben sind? Auch hier nach Krug: “Wenn es mir Spaß bereitet, meine Website aktuell und mit den neusten Angeboten zu versehen, steigert das auch die Usability der Seite?” Gerade bei großen TYPO3-Projekten, die sehr viele Plugins und Extensions benötigen, sind Kunden und Redakteure meist vom benutzerunfreundlichen Interface von TYPO3 überfordert und frustriert. Wem ist nicht schon bei perfekt konzipierten Frontends, die der Kunde liebt, das Schnaufen während der TYPO3-Schulung das überforderte Schnaufen untergekommen. Dass dies nichts Neues ist, dürfte jedem, der mit TYPO3 täglich zu tun hat, bekannt sein.

Plugin Konzeption einmal überdacht

Aufgrund der Struktur von TYPO3 ist es kaum möglich als Freelancer oder Agentur allen selbst geschriebenen Extensions ein zur Aufgabe passendes, Usability-optimiertes Interface zu verpassen. Insbesondere das Eintragen von Datensätzen im List-Modul ist kaum ohne mehrere Manntage Aufwand in ein neues Gewand zu pressen und das ist dann auch nicht der Sinn bei einem Open Source CMS wie TYPO3.
Eine Lösung wäre aber schon bei der Konzeption von dynamischen Frontendinhalten, die Logik der Inhalte auch im Backendplugin abzubilden. Eine Feld zeigt sich im Frontend nicht, wenn es nicht gebraucht wird? Dann ist es auch nutzlos im Backend. Warum den Redakteur mit leeren Feldern überfordern?
Die Vorteile liegen auf der Hand

• Schnellere, effizientere Arbeit des Redakteurs
• Weniger Fehler durch logisches Führen des Redakteurs durch den Einpflegeprozess
• Motivierter Mitarbeiter
• Konzentration auf den Inhalt, nicht auf den Prozess
• Zufriedenere Kunden
• Weniger Supportanfragen

Realisiert werden kann dies zum Beispiel durch den Einsatz von JavaScript im Backend von TYPO3. Dem Backend von TYPO3 kann über TSConfig JavaScript hinzugefügt werden, das das Ein- oder Ausblenden von Feldern, Abbilden von Logiken des Frontends oder Benutzerunterstützung abbilden kann. In Backendmodulen ist das Einbinden von JS dankbar einfach, da es innerhalb eines <script>-Tags in der index.php des Backendmoduls eingefügt werden kann.

Frontendprinzipien für das Backend

Nur weil der normale Websiteuser das Backend so gut wie nie zu sehen bekommt, heißt das nicht, dass der Benutzer nicht von einem durch Usability motiviertem Redakteur profitieren kann. Alleine dadurch, dass Fehler beim Einpflegen vermieden werden, entsteht dem Nutzer schon ein Mehrwert. Wird Benutzerfreundlichkeit im Frontend zur Zeit entweder vernachlässigt oder überwertet, so kann das Einführen von einigen Usability-Prinzipien im Backend die Kundenzufriedenheit stark erhöhen.
Der erhöhte Aufwand beim Schreiben des JavaScripts oder CSS für das Backend ist sehr schnell durch verringerte Supportzeit beim Kunden verargumentiert und die Dankbarkeit von z.B Shop- oder Newsredakteuren ist der Agentur oder dem Freelancer sicher.

Folgender Ausgangspunkt sei gegeben:

Man möchte dem Nutzer die Möglichkeit geben, dass er bestimmte Einstellungen sowohl im TypoScript als auch im FlexForm-Formular machen kann. Zum Beispiel die Eingabe einer Breite. Dies würde für die flexform-XML ungefähr diesen Code bedeuten:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<T3DataStructure>
	<meta>
		<langDisable>1</langDisable>
	</meta>
	<sheets>
<configurationsSheet>
			<ROOT>
				<TCEforms>
					<sheetTitle>LLL:EXT:my_extension/locallang_db.xml:configSheet</sheetTitle>
				</TCEforms>
				<type>array</type>
				<el>
<width>
						<TCEforms>
							<label>LLL:EXT:my_extension/locallang_db.xml:tx_my_extension_fedata.width</label>
							<config>
								<type>text</type>
								<cols>30</cols>
								<rows>1</rows>
							</config>
						</TCEforms>
					</width>
</el>
			</ROOT>
		</configurationsSheet>
</sheets>
</T3DataStructure>

Befindet sich in der setup.txt-Datei ebenfalls eine Konfigurationseigenschaft mit dem Namen width, so würde dieser Wert durch das lib/div-Framework immer überschrieben werden – selbst dann, wenn in der Flexform, das Feld leer gelassen würde.

plugin.tx_my_extension.configuration {
width = 800
}

Um dieses Verhalten zu umgehen muss die Funktion

public function setFlexFormConfiguration($xmlOrArray)

überschrieben werden.
Für die Extension benötigt ihr demnach eine Configurations-Klasse, die von tx_lib_configurations erbt. Dies kann so aussehen:

tx_div::load('tx_lib_configurations');
 
class tx_my_extension_configurations extends tx_lib_configurations {
	private $setupPath = 'plugin.tx_my_extension_configurations.';
}

In der default-Controller-Klasse muss eure Configurations-Klasse natürlich angegeben sein.

class tx_my_extension_controller_default extends tx_lib_controller {
	private $extKey = "my_extension";
	public $configurationsClassName = 'tx_my_extension_configurations';

Im nächsten Schritt ist die bereits oben erwähnte Funktion setFlexFormConfiguration mit foldendem Code zu überschreiben.

public function setFlexFormConfiguration($xmlOrArray) {
		$languagePointer = 'lDEF'; // we don't support languages here for now
		$valuePointer = 'vDEF'; // also hardcoded here
		if (!$xmlOrArray) {
			return false;
		}
		// Converting flexform data into array if neccessary
		if (is_array($xmlOrArray)) {
			$array = $xmlOrArray;
		} else {
			$array = t3lib_div::xml2array($xmlOrArray);
		}
		$data = $array['data'];
		//
		foreach((array) $data as $sheet => $languages) {
        	foreach((array) $languages[$languagePointer] as $key => $def) {
                // just use ff value if something was entered
                if ($def[$valuePointer] != '') {
                        $this->set($key, $def[$valuePointer]);
                }
        	}
		}
	}

Bis auf

 // just use flexform value if it's not empty
                if ($def[$valuePointer] != '') {
                        $this->set($key, $def[$valuePointer]);
                }

ist die Funktion aus der Super-Klasse tx_lib_configurations kopiert worden. Durch den obigen Code wird der FlexForm-Wert nur genommen, wenn auch etwas eingetragen wurde. Diese Logik erscheint mir sinnvoller als das Vorgehen des Frameworks vor der Korrektur.
Zu guter Letzt tragt ihr die überschriebene Funktion in euere Configurations-Klasse ein, so dass diese nun so aussehen sollte.

class tx_my_extension_configurations extends tx_lib_configurations {
	private $setupPath = 'plugin.tx_my_extension_configurations.';
 
public function setFlexFormConfiguration($xmlOrArray) {
		$languagePointer = 'lDEF'; // we don't support languages here for now
		$valuePointer = 'vDEF'; // also hardcoded here
		if (!$xmlOrArray) {
			return false;
		}
		// Converting flexform data into array if neccessary
		if (is_array($xmlOrArray)) {
			$array = $xmlOrArray;
		} else {
			$array = t3lib_div::xml2array($xmlOrArray);
		}
		$data = $array['data'];
		//
		foreach((array) $data as $sheet => $languages) {
        	foreach((array) $languages[$languagePointer] as $key => $def) {
                // just use ff value if something was entered
                if ($def[$valuePointer] != '') {
                        $this->set($key, $def[$valuePointer]);
                }
        	}
		}
	}
}

Zu finden ist die Extension im Repository unter http://typo3.org/extensions/repository/view/mwflash2t3/current/. Die Dokumentation enthält ein Schritt-für-Schritt-Tutorial, um die Funktionsweise nachzuvollziehen. Darüber hinaus ist die Extension sehr flexibel aufgebaut und kann sowohl per Flexform als auch per TypoScript konfiguriert werden.
Sie basiert im Fronten-Plugin auf lib/div und wird so hoffentlich gut in die nächsten Generationen von TYPO3 integrierbar sein.
Ein Beispiel bietet die Website http://typo3fl.webseiten.cc/. Sie ist eine Full-Flash-Site und wird über meine Extension und TYPO3 verwaltet.

Für Fragen und Antworten zur Extension steht die Kommentarfunktion zu Verfügung. Ich würde mich über Verbesserungen, gewünschte Features in der nächsten Version, Lob, Kritik und vieles mehr freuen. Ich denke, mit dieser Extension ist ein Anfang für die Zusammenarbeit und die Verwaltung von TYPO3 und Flash getan.

Hier findet ihr die Dokumenation als PDF. Mir vielen Screenshots und Tutorial. mwflash2t3-Dokumentation

Wenn ich die Programmierung aufgearbeitet habe, werde ich einige kleine Tutorials zur Extension-Programmierung hier bereit stellen. Bis dahin…

Die Extension wird in Frontend- und Backendfunktionen aufgeteilt. Im Frontend kann man die Extension sowohl als neuen Pagetype als auch als Plugin einfügen. Der neue Pagetype ist für komplette Flashsites gedacht. Das Plugin für ein einzelnes Flashmodul auf der Website. Das Frontendplugin wird zukuftsgerecht mit den lib/div Extension programmiert. Ich verspreche mir davon, dass es später für mich einfacher wird auf TYPO3 v5 zu switchen.
Das Backendmodul versteckt sich dann unter WEB im TYPO3-Backend. Hier wählt der Nutzer seine XML aus und mappt nach TemplaVoilà-Art. Ich hoffe, dass ich es zeitlich schaffe, dass die XML, ohne vorherige Eingabe der Node-Namen durch den User gemappt werden kann.
Beim Datenbankaufbau habe ich mich an TemplaVoila orientiert. Auch ich werde mit der Trennung zwischen Templateobject und Datastructure arbeiten. Da bei mir aber sowohl Frontend wie Backend Zugriff auf die XML brauchen, gibt es bei mir eine eigene Tabelle für die XML. Auch für die Daten aus der Flexform des Plugins stelle ich eine eigene Tabelle zur Verfügung.

Schade ist, dass TemplaVoilà das Mappen von XML nicht unterstützt. Interessant ist aber, dass dies anscheinend einmal angedacht war. In der Datei class.tx_templavoila_htmlmarkup.php befindet sich die Funktion setTagsFromXML ( $content )

	/**
	 * The idea is to parse the XML in $contnet and set the internal TAG array with all these tags so they can be mapped...
	 * NOT WORKING YET - experiment.
	 *
	 * @param	[type]		$content: ...
	 * @return	[type]		...
	 */
	function setTagsFromXML($content)	{
		$parser = xml_parser_create();
		$vals = array();
		$index = array();
 
		xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, 0);
		xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 0);
		xml_parse_into_struct($parser, $content, $vals, $index);
 
		if (xml_get_error_code($parser))	return 'Line '.xml_get_current_line_number($parser).': '.xml_error_string(xml_get_error_code($parser));
		xml_parser_free($parser);
 
		$this->tags = $index;
		foreach($index as $idx => $value)	{
			$this->tags[$idx] = array();
		}
		print_r ($this->tags);
 
		$this->textGnyf = 1;
	}

Allerdings wird diese Funktion nie benutzt und ist sogar in der index.php des cm1-Ordners der Extension in der Funktion

function displayFileContentWithMarkup($content,$path,$relPathFix,$limitTags)

eingebaut, aber auskommentiert.

/**
	 * This will mark up the part of the HTML file which is pointed to by $path
	 *
	 * @param	string		The file content as a string
	 * @param	string		The "HTML-path" to split by
	 * @param	string		The rel-path string to fix images/links with.
	 * @param	string		List of tags to show
	 * @return	void		Exits...
	 * @see main_display()
	 */
	function displayFileContentWithMarkup($content,$path,$relPathFix,$limitTags)	{
		$markupObj = t3lib_div::makeInstance('tx_templavoila_htmlmarkup');
		$markupObj->gnyfImgAdd = $this->show ? '' : 'onclick="return parent.updPath(\'###PATH###\');"';
		$markupObj->pathPrefix = $path?$path.'|':'';
		$markupObj->onlyElements = $limitTags;
 
		// $markupObj->setTagsFromXML($content);
 
		$cParts = $markupObj->splitByPath($content,$path);
		if (is_array($cParts))	{
			$cParts[1] = $markupObj->markupHTMLcontent(
							$cParts[1],
							$GLOBALS['BACK_PATH'],
							$relPathFix,
							implode(',',array_keys($markupObj->tags)),
							$this->MOD_SETTINGS['displayMode']
						);
			$cParts[0] = $markupObj->passthroughHTMLcontent($cParts[0],$relPathFix,$this->MOD_SETTINGS['displayMode']);
			$cParts[2] = $markupObj->passthroughHTMLcontent($cParts[2],$relPathFix,$this->MOD_SETTINGS['displayMode']);
			if (trim($cParts[0]))	{
				$cParts[1]='<a name="_MARKED_UP_ELEMENT"></a>'.$cParts[1];
			}
			return implode('',$cParts);
		}
		$this->displayFrameError($cParts);
		return '';
	}

Leider, leider, leider bietet TemplaVoilà hier keinen Hook an, weshalb ich keinen Weg sehe, die Funktionalität, die ich benötigen würde, auf vernünftige Weise einzubauen. Per XCLASS zu erweitern, erscheint mir nicht sonderlich sinnvoll.

Was ich allerdings an dem neuen Ansatz lib/div noch nicht sehe, ist die Möglichkeit für das Backend mit dem MVC-Model zu programmieren. Es scheint ein Feature nur für Frontend-Plugins zu sein. Falls ich mich hier irre, lasse ich mich gerne berichtigen. Aber ich denke, dass mir für das Backendmodul nur der Weg über den Aufbau index.php + weitere Aspektorientierte Klassen gehen kann.

Anregungen, Tipps oder Kritik gerne hier posten.

Als Debugger habe ich Arthropod von Carl Calderon benutzt. Auf diesen bin ich irgendwann gestoßen und er hat mich bisher nicht entäuscht. Ich glaube zwar, dass der Debugger nicht mehr sonderlich stark weiterentwickelt wird, aber da er auf Adobe Air basiert ist er einfach universal einsetzbar.
Ich habe die Debugger-Klasse jetzt nicht entfernt und es sind glaube ich auch noch ein paar Debug-Aufrufe im Quellcode. Wen das stört, kann sie gerne rausschmeißen.

Wenn ich Zeit finde, werde ich auch gerne mal ein Tutorial über den Aufbau des Flashmoduls schreiben. Ich habe mich unter folgenden Adressen schlau gemacht:

• http://puremvc.org/
• http://hubflanger.com/building-a-flash-site-using-puremvc/
• http://www.flexughh.de/downloads/meetings/280308/

Die XML site.xml enthält die Daten für die Website. Da ich den Content ja dann in TYPO3 einfüllen werde, ist das Ganze natürlich eher als Template gehalten. Aber ich denke die Strukur erklärt sich von selbst, da das ganze Frontend ja nur ein Beispiel für die Funktionsweise der Extension sein soll.

Bugs, Vorschläge oder Ähnliches einfach als Kommentar unter den Post.

T3lovesFlash

Über ein paar möchte ich hier Auskunft geben, um vielleicht dem einem oder anderen bei der Fehlersuche behilflich zu sein.

Fehler: Es wird kein Text angezeigt

Einbetten von Schriften

Denkt daran eure Schriften einzubetten. Wenn ihr dynamisch Textfelder zur Bühne hinzufügt, müssen alle Zeichen eures Zeichensatzes, die ihr benutzen wollt, eingebettet sein. Das macht ihr über den Einbetten-Button, nachdem ihr das dynamische Textfeld auf der Bühne selektiert habt.

Im auftauchenden Fenster wählt ihr die Zeichen aus, die ihr benötigen werdet. Vergesst nicht die deutschen Umlaute einzubauen (natürlich nur, wenn es eine deutsche Seite ist). Die sind nämlich in Flashs Auswahl für Groß- und Kleinbuchstaben nicht vorhanden. Ist dann in eurem Text, den ihr dynamisch hinzufügt, ein Umlaut vorhanden, zeigt Flash euren Text nicht an.

Bei vollkommen dynamisch hinzugefügten Textfeldern müsst mit der Eigenschaft

TextField.embedFont = true;

das einbetten von Fonts erlauben und mit der TextFormat-Klasse einen Font definieren.

TextFormat.font = "Verdana";

Weitere Infos im LiveDoc von Adobe zu dem Thema.

Fehler: Trotz einbetten der Glyphen, zeigt Flash keinen Text an

Mitkompilieren des Zeichensatzes

Ihr habt eure Glyphen im Textfeld eingebettet, allerdings wird auf einem anderen Computer kein Text eingezeigt. Hier liegt es meistens daran, dass die Schrift, die ihr verwendet nicht auf dem fremden Computer vorhanden ist. Die Einbetten-Funktion bei Flash ist dabei etwas missverständlich gekennzeichnet. Beim Einbetten bettet ihr nicht die Schrift selber ein, sondern sagt dem Textfeld nur, welche Glyphen im Textfeld dargestellt werden sollen. Ist eure Schrift aber nicht auf dem fremden Computer vorhanden, kann den Flash die passenden Buchstaben nicht mehr darstellen. Deshalb ist es wichtig, dass ihr eure Schriftart in der Bibliothek mitkompiliert.

Das macht ihr über das Kontextmenü der Bibliothek. Hier wählt ihr neue Schriftart.

Im auftauchenden Dialogfenster legt ihr eure Schrift dann an und speichert sie in die Bibliothek. Wichtig: Für jede Größe und Art eurer Schrift, die ihr in eurem Flash verwendet, also zum Beispiel “Webdings”, 16pt und fett und “Webdings”, 14pt und normal, müsst ihr eine eigene Schrift anlegen. Es reicht nicht, einmal “Webdings” in 16pt in die Bibliothek zu importieren.

Der Nachteil an diesem Verfahren ist natürlich, dass der Flashfilm in der Größe wächst. Deshalb sollte genau überlegt werden, welche Glyphen und Schriftarten wirklich benötigt werden.

Fehler: Beim dynamischen Einladen von Texten, werden diese verzerrt oder an falscher Position dargestellt

Sind TextFieldAutoSize-Konstanten gesetzt und der Parent-MovieClip nicht verzerrt

Es ist leider unbedingt von Nöten bei dynamischen Textfeldern die Konstanten der TextFieldAutoSize an das Textfeld zu übergeben. ActionScript 3 setzt den Default-Wert für TextField.autoSize auf NONE, weshalb dieser unbedingt im Quellcode übergeben werden muss, da sich sonst die dynamischen Textfelder nicht an die Größe des übergebenen Textes anpasst. Hierfür sind die Konstanten der Klasse TextFieldAutoSize zuständig (LiveDoc). Folgende Optionen

TextFieldAutoSize.LEFT
TextFieldAutoSize.NONE (default)
TextFieldAutoSize.RIGHT
TextFieldAutoSize.CENTER

sind verfügbar. Dummerweise ist der default-Wert für die Erstellung einer Navigation nicht brauchbar (zumindest war es bei mir so).  Denn mit dem Default-Wert behalten die Textfelder ihre Größe und passen sich nicht an der Inhalt an. Wenn ich nun den Abstand zwischen den Navigationspunkten berechnen will bekomme ich falsche Wert und die Navigationspunkte verschieben sich.

Ein weiteres, nerviges Verhalten ergibt sich, wenn dynamische Textfelder in MovieClips geladen werden, die eine Transformation erfahren haben. Die nachgeladenen Textfelder verzerren ebenfalls und ändern ihre Größe. Falls ihr dieses Problem auch beobachtet, so ist eine Lösung, die Textfelder in einen leeren, frischen MovieClip außerhalb des transformierten Clips zu laden.

Im Großen und Ganz gehört die TextField-Klasse, neben der Tween-Klasse, zu den Klassen, die mir am meisten Probleme bereitet haben. Entweder durch schlechte Dokumentation oder durch “verbuggtes” Verhalten. Würde mich freuen, wenn der eine oder andere seine Erfahrungen mit diesen beiden Klassen posten könnte. Vielleicht kriegen wir eine schöne Bug-Sammlung zusammen und es wird eine Hilfe für andere.

Kleiner Nachtrag für die Bugsammlung:
Wenn Ihr ein TextFormat auf ein TextField anwendet, müsst ihr das TextFormat NACH der Zuweisung des Textes machen. Beispiel:

var meinText : TextField = new Textfield ();
var meinTextFormat : TextFormat = new TextFormat ();
meinTextFormat.size = 16;
meinTextFormat.color = 0xFF00FF;
meinTextFormat.font = "Verdana";
 
meinText.text = "Mein Text";
linktitle.setTextFormat ( tf );