Gestaltungsprozess vs. OOP

Als studierter Kommunikationsdesigner, weiß ich natürlich, das es die  beliebteste Herangehensweise an ein grafisches, somit auch an ein Flashprojekt ist, nach und nach Einzelteile hinzuzufügen und dabei eine Flashdatei zu kreieren, die dabei langsam zu einer Gesammtheit wächst. Dieser Prozeß ist zwar kreativ aber bereits im Ansatz 100% prozessorientiert, heißt ja auch so: "Gestaltungsprozeß". Der  Versuch daraus das genaue Gegenteil, nämlich eine funktionierende, objektorientierte Programmstrucktur zu entwickeln, führt beinahe zwangsläufig, zu einem gnadenlosen Desater, welches nach der Überführung in ein Zwischenstadium von schier unüberwindbarem Chaos,  als einzig letzten Ausweg, den kompletten Neustart des gesammten Projekts zulassen wird und zwar in einer exponential ansteigend Problemerscheinungskurve. Beginnend mit zunächst kleineren Problemen der Anwendung Funktionalität beizubringen,  wachsen die Probleme mit zunehmender Kompexität, exponential an und lässt gegen Ende jede noch so kleine Änderung zu einem mörderischen Gewaltakt gedeihen, bei dem für Miniänderungen die komplette Anwendung umgeschrieben werden muss. Bis es schlicht nicht mehr geht, weil man durch das Ausbügeln von Fehlern an einem Ende, doppelt so viele Neue an einem anderen Ende hinzufügt und man sich in einer brutalen Abwärtsspirale dem absoluten Nullpunkt nähert. Zu diesem Zeitpunkt, wird bereits  nichts mehr verhindern können, daß man hart auf dem Boden der Realität einschlägt und einem Nichts übrig bleiben wird, ausser endlose Zeilen wertloser Code-Schrott und der schmerzhaft, bitteren Erkenntnis, das es "geht nicht", irgendwie doch gibt und zwar genau vor der eigenen Nase.

Gliederung des Workflow
(MVC) Model - View - Controller Objektorientierter Programmieransatz als Gliederung für den Workflow
Das Briefing
Aufteilung der Kompetenzen zwischen Konzeption, Kreation und Programmierung.
Der Entwurf
Entwurf einer Elemente Sammlung
Entwicklung
Herstellung der Funktionalität mit Dummy Objekten.
Finishing
Zusammenfügen und testen der Applikation.

Dynamisch - Statisch

Da die Begriffe auf unserer Website öfter verwendet werden, erklären wir hier kurz den Kontext. Eine "statische" Anwendung, ist eine Flashanwendung, die aus einzelnen  Objekten zusammengebaut und anschliessend kompiliert wird. In einer  solchen Anwendung, ist es nicht möglich zur Laufzeit der .swf Datei  weitere Komponenten hinzuzufügen. Sie ist deshalb "statisch". Diese, kann man zwar in einem CMS anzeigen, ihren Inhalt oder ihr Aussehen, in Relation zu den, aus der Datenbank gelieferten Daten, verändern, kann man aber nicht. Einen wirklichen Sinn, im Sinne eines Contentmanagements, macht erst die Möglichkeit die Datenbankdaten verwenden zu können um  damit Inhalt und Aussehen der Anwendung zu verändern. Da diese Daten zur Kompilierzeit der .swf Datei aber nicht bekannt sein können, kann man keine statische Flashdatei dazu verwenden. Wir brauchen eine .swf Datei, die nur eine "Bauanleitung" zu den entspechenden, aus den Datenbankdaten zu erstellenden Objekten, enthält. Mit Actionscript 3.0 ist es möglich, solche "Bauanleitungen" zu  schreiben, die zur Laufzeit, Flashobjekte herstellen und diese  auf  einer Website darstellen. Dies bildet die Grundlage dafür "managebare"  Anwendungen in Flash zu erstellen. Da eine solche Datei, in der Lage  ist Ihre Erscheinung, während ihrer Laufzeit, an die jeweiligen Erfordernisse anzupassen, nennen wir  sie "dynamisch". In der Realität gibt es oft Mischformen, in AS 2.0 war es üblich, .swf Dateien mit statischen und dynamischen Anteilen zu verwenden. Unsere Flash Player sind z.B. solche .swf Dateien, während unsere Navigationen komplett dynamisch erzeugte .swf Dateien sind. Heißt: Klickt man hier oben auf "Leistung", wird 100% die selbe .swf Datei angezeigt, wie wenn Sie auf "Produkte" klicken, Ihr wird lediglich ein anderes Datenmaterial für den Zusammenbau geliefert. Im strengen Sinne, eines CMS bedeuted das 100% ige Trennung zwischen Form und Inhalt.