<Download Gugga Flash Framework>

Thursday, September 20, 2007

GuggaFF is now on ActionScript 3.0

We this new feature we would like to announce our long anticipated plans for moving the Gugga Flash framework to ActionScript 3.0 have become a reality and we can share its first alfa release. This turned out to be a very complicated task since the whole concept of making interactive sites and applications with Flash is changing completely with the release of Flex 2 and Flash CS3. That’s why we decided to identify the unique features that we believe will continue to exist and will contribute most to the whole development process, and port them first.

The primary features which we decided to include in this first ActionScript 3.0 release of the framework is the Tasks Engine. Along with it are included some other aspects which support its functionality such as Collections, Logging and variety of utilities.

Tasks engine is very powerful and in the same time its abstract enough. It can be combined with different concepts already included in Flex and Flash CS3. One can imagine tools combining XML defined animations from Flash CS3 and effects from Flex wrapped and included in a GuggaFF task sequence or sequences wrapped and used as effect in Flex.
There are still no implemented wrappers for doing so but they are possible to implement and will probably be included in some of the next releases.

Our major goal is to provide a full featured framework which will complement the Adobe’s suite of tools for creating interactive sites and applications. The scope and concepts of the framework will change over time as the basis of the tools we currently have has changed so much but we promise that all that we learn will be shared, with more examples and refined best practices.

You can download the new alfa release from here:
Alfa Version 2.0 alfa

Tuesday, June 26, 2007

Building multimarket applications with Gugga Flash Framework.

Creating applications with dynamic structure.

With this new article we would like to offer you a flexible solution for creating a Multimarket-Multilanguage Flash Applications using GuggaFF. We will see how such RIAs can achieve a highly flexible and extensible structure accommodating future changes and updates. Based on our own experience, those kind of applications are usually requested to serve specific business reasons providing customized information to many markets in different languages. Let summarize the requirements for our application

  • provide customized information and functionality to more then one market in more then one language

  • allow for transparent update of information without the need to recompile the application

  • ability to quickly release or disable whole sections of the application during its lifespan

  • build and release new markets and languages without jeopardizing the existing functionality and without rewriting the application

  • allow for creating Accessible versions of the applications reusing the existing content

  • allow for transparent introduction of a content management system to support the application

Sounds familiar ….?
Ok let’s look at the two important aspects of our application that make it so unique as a requirement.

Market
A very common scenario is that different markets involve different structure of the application at the same time there is usually a significant overlap and single section is found among more than one market. Hence, market determines a set of sections with specific structure.
Please, remember that Gugga Flash Framework introduces Sections and SectionsControllers as the building blocks of an application.
Take a look at them, if they are new to you!

Language
Language is usually a function of the content displayed in the site. We will assume that all the content in our application will be external to it and will either be held in static XML files or in a Data Base.

Our goal is to create a single application which supports variable sections structure, in order to represent different markets. We strive to reach the lowest development cost in the long term and preserve high quality on a large scale.

The main architectural problems our solution is faced with are:

  • How to define flexible application structure, which also allows transparent creation of new markets?

  • How to implement an application which supports variable section structures?


How to define flexible application structure, which also allows transparent creation of new markets

Our best approach in defining the sections structure is to use xml format. It is hierarchical and matches the composite structure of the sections. Its declarative style allows even non-developer to create and control it. More importantly, the xml format brings formal sense to the key abstraction of an application structure. It also ensures that the application is completely abstracted of its current structure. For convenience proposes we will call that xml file structure.xml

Let’s start with declaring the main building block of our application - the section within the structure.xml. We will create a
node which will basically need:

  • id – identifier of the section. It will be used in the section paths used by GuggaFF navigation mechanism
    Please, remember that every section within the composite is identified by a dot-notated section path. NavigationCommands are used to navigate section paths.

  • typeon_stage, lazy_attach or lazy_load depending on that if the section is on the application stage or in the application library or in external swf file. GuggaFF supports all types of sections by registerChildSection, registerLazyAttachSection and registerLazyLoadSection methods of the SectionsController class. The on_stage type of section is not the best approach if we want a flexible solution but in some very special cases (ex. when we want to abstract a block of sections which always go together) we can use it. This kind of sections are opening faster, because they are loaded and initialized in advance.

  • instance – For on_stage type of sections.

  • symbol_identifier – For lazy_attach type of sections.

  • swf_path – For lazy_load type of sections.


Here is a sample node of a generic section declaration:

<section id="Home" symbol_identifier="HomeSection" type="lazy_attach">
<section id=”SubSection” … </section>
</section>
If we could point any drawbacks of this solution, it is that we should have separate structures even for identical markets. But this is a cheap price to be paid!

How to implement an application which supports variable section structures





In GuggaFF every SectionsController registers its child sections. Given that, we need SectionsControllers which accept structure data(coming from structure.xml) which they will use to register their child sections. We will subclass SectionsController and this will bring a new quality to the composite entity – the ability to be created dynamically.

Here is some pseudo code to illustrate the idea.

Interface extension for composite nodes:
interface sections.IBaseSection extends ISection 

{

public function
setStructureData(aData : SectionStructureData) : Void;
}


Subclass of SectionsController to carry out the structure data and register child sections:

class configuration.SectionStructureData 

{

public var
ID : String;
public var
Type : String;

public var
SymbolIdentifier : String;
public var
Swf : String;

public var
Instance : String;
public var
Subsections : Array;

public var
SectionPath : String;
}


Subclass of SectionsController to carry out the structure data and register child sections:

class sections.BaseSectionsController extends SectionsController implements IBaseSection 

{

public function
setStructureData(aData : SectionStructureData) : Void
{


mStructureData = aData;

var
subsectionsStructureData : Array = aData.Subsections;

for
(var i : Number = 0; i < subsectionsStructureData.length; i++)
{


var
data : SectionStructureData =
SectionStructureData(subsectionsStructureData[i]);


if
(data.Type != "on_stage")
{

mSectionLoadersCount++;
var
sectionLoader : ISectionLoader =
createSectionLoader(data, "sectionLoader_" + data.ID + "_" + mSectionLoadersCount);


registerLazySection(sectionLoader, data.ID, true);
}

else


{

var
section : Object = registerChildSection(data.Instance, data.ID);

IBaseSection(section).setStructureData(data);
}


mSubsectionsStructureData.add(data.ID, data);
}
}


private function
onLazyTargetSectionUIInitialized(ev) : Void
{

var
section : IBaseSection = IBaseSection(ev.section);

var
data : SectionStructureData = SectionStructureData(
mSubsectionsStructureData[mTargetSectionID]);

section.setStructureData(data);
}
}


To use the structre functionality of the BaseSectionsController from classes which derives from SectionsController (ex. ApplicationController), we can use the Bridge pattern.

These pseudo-implementations create the foundation of our solution for applications with dynamic structure. Every section which derives from IBaseSection or BaseSectionsController will be of a full value for the application with dynamic structure.

In next postings we will explain additional aspects of the multimarket applications like, strategies for implementing sections and components, skinning and creating accessible version of a flash site build using GuggaFF.

Monday, May 14, 2007

The new Minor(major) release of Gugga Flash Framework

The new release of the GuggaFF is introducing a number of changes and improvements. The majority are focused on performance increase and improved application model.

The most significant change in is the Application Architecture. Now the ApplicationController class is a kind of Front Controller for the application. It controls all the transitions in the application and is responsible for the navigation state. Transition starts and interruptions are handled by the ApplicationController so the lower level SectionControllers are no more responsible for this. Their job is to provide the openSection() method and return the transition between the sections they are responsible for. The openSection() method of the ApplicationController should not be called separately. The navigateTo() should be called instead.

In addition to the ApplicationController changes the navigation’s state can be set by specifying the section path which is currently available. This synchronization is made by the gugga.application.NavigationManager which is commanded by the ApplicationController. Every navigation instance which is registered in the NavigationManager will follow the changes in the application’s section path automatically.

Having the ApplicationController as a Front Controller gives a much better level of control and synchronization, so now we have much better transitions interruptions. To support all the cases of fast transition changes the navigateTo() method can refuse to open a certain navigation path. In this case it returns false and the corresponding command is not included in the CommandHistory.

The other major change in this release is that GuggaFF has become almost completely separated from the Macromedia MX framework. We have our own implementation of EventDispatcher with the gugga.events.EventDispatcher class. It uses AsBroadcaster and provides significant increase in performance. In addition, the gugga.common.UIComponentEx is not inheriting mx.core.UIObject. This makes the framework more performing and decreases the time needed to initialize an application. The only link between GuggaFF and MX remains the mx.utils.Delegate class.

Another big step in increasing the performance is the new gugga.tween package. It provides a lightweight but powerful tween engine. It supports both tweens with frames duration and tweens with time duration. This helps to tune the speed and smoothness of the animations even better.

For a complete list of changes please see the change log.

Friday, November 17, 2006

Anatomy of a Button in GuggaFF

The gugga.components.Button class in GuggaFF is designed to provide functionality for managing the visual states of a button and to inform for mouse events over it.

Mouse events which the Button dispatches are “click”, “press”, “rollOver”, “rollOut”. On all of them it can change its appearance. In addition the button can be in one of its selection states which also determines certain visualization.

Selection states:
  • off – button is not selected
  • on – button is selected
  • offDisable – button is disabled and is not selected
  • onDisable – button is disabled and selected

    Mouse states:
  • Roll – mouse is rolled over the button
  • Down – button is pressed
  • Normal – none of the above is happening

    In each moment of its life a button is in one of its selection states and one of the mouse states. Selection and mouse states are combined together to represent the unified button state. Here is the table of all possible states:




    Let's take a closer look at some of the button states:
  • offRoll is when button is not selected but is rolled
  • onDisableRoll is when button is selected, disabled and rolled
  • offDisableDown, onDisableDown – the only two combinations which are impossible because when button is disabled it can’t be pressed

    Now if we want to transit from one state to another we can create transition. Its name is generated with this pattern: oldState_newState, for example - off_offRoll.

    Each button is a MovieClip with linked gugga.components.Button class to it. Button states and transitions are placed on the button’s timeline. They are marked with frame labels named as the state or transition’s name. On the end of each of these timeline segments, where the certain animation is finished, the stopPlaying() function should be called. If we want two, three or more states to be identical, we don’t need to create portions of the timeline for each of them. Despite this we could simply put several labels on the frame where the desired state or transition animation starts.

    There are 10 button states and because it is possible to go from each state to all others, we have 9*10=90 transitions. Do we have to create all of them?
    Of course not.

    The main idea in the implementation of GuggaFF Button is that we should create only those states and transitions which we need. When the button goes to another state, it first tries to play transition with name made by the pattern oldState_newState. If there is such a transition the button plays it and when it is finished the button tries to play the newState.
    If this transition does not exist then newState is played directly.
    If we have neighter transition, nor state – nothing happens.
  • Friday, October 20, 2006

    Basics of Tasks and Sequences in GuggaFF

    Overview

    With this new article we would like to introduce you to one of the most important aspects of the GuggaFF, the concept of tasks and sequences and their applications. We will start with one example and how it is usually handled in Flash.

    Let’s examine an abstract GUI application with dynamic content implemented in Flash. One of our first tasks will be to extract the application data from our data source. It doesn't matter what of kind of data source you are using - http service, web service or simple xml file it will take a while to load and process the data. Fortunately data loading in the Flash runs in background thread, so we can implement a loading animation which will capture the user attention during these tasks. After the data is loaded we'll want to populate the controls responsible for its presentation. This example may scale to a situation where depending on the size of the data the process may need to be distributed on more than one frame to achieve the desired performance.

    In more complex sites we will need to implement the ability to have more then one view (also known as sections in GuggaFF) or different states of the view. Depending on user interactions we will need to switch the current section or to change its internal state. Often this operations are composition of loading and transition animations, preloading of external assets etc.

    Common problems

    During the implementation of a site in Flash we will need to handle a lot of asynchronous operations. The base approach is to register an event handler for the completion of the operation and use it to continue our work after the asynchronous task is finished. If you are using the event delegation mechanism of mx framework it would be something like this:
    private var mImageLoader : ImageLoader;

    private function loadContent(aImageUrl : String) : Void
    {
    mImageLoader.addEventListener("completed", Delegate.create(this, onImageLoaderCompleted));
    mImageLoader.load(aImageUrl);
    }

    private function onImageLoaderCompleted() : Void
    {
    //do something (ex. hide loading animation or start another loader)
    }


    Now imagine that we want to implement a functionality which is a sequence of asynchronous operations. If we scale this approach the resulting code will be:
    private var mAnimation1 : IAnimation;
    private var mAnimation2 : IAnimation;
    private var mAnimation3 : IAnimation;

    private function initUI() : Void
    {
    mAnimation1.addEventListener("completed", Delegate.create(this, onAnimation1Completed));
    mAnimation2.addEventListener("completed", Delegate.create(this, onAnimation2Completed));
    mAnimation3.addEventListener("completed", Delegate.create(this, onAnimation3Completed));
    }

    private function startAnimationsSequence() : Void
    {
    mAnimation1.start();
    }

    private function onAnimation1Completed() : Void
    {
    mAnimation2.start();
    }

    private function onAnimation2Completed() : Void
    {
    mAnimation3.start();
    }

    private function onAnimation3Completed() : Void
    {
    //do something (ex. notify for the completion of the sequence)
    }


    Also if we need to wait for more than one event before we can execute some function one of the possible solutions is:
    private var mImageLoader1 : ImageLoader;
    private var mImageLoader2 : ImageLoader;

    private var mIsImageLoader1Completed : Boolean;
    private var mIsImageLoader2Completed : Boolean;

    private function initUI() : Void
    {
    mImageLoader1.addEventListener("completed", Delegate.create(this, onImageLoader1Completed));
    mImageLoader2.addEventListener("completed", Delegate.create(this, onImageLoader2Completed));
    }

    private function loadConent(aUrl1 : String, aUrl2 : String) : Void
    {
    mIsImageLoader1Completed = false;
    mIsImageLoader2Completed = false;

    mImageLoader1.load(aUrl1);
    mImageLoader2.load(aUrl2);
    }

    private function onImageLoadersCompleted() : Void
    {
    //do something (ex. start reveal animation)
    }

    private function onImageLoader1Completed() : Void
    {
    mIsImageLoader1Completed = true;
    if(mIsImageLoader2Completed)
    {
    onImageLoadersCompleted();
    }
    }

    private function onImageLoader2Completed() : Void
    {
    mIsImageLoader2Completed = true;
    if(mIsImageLoader1Completed)
    {
    onImageLoadersCompleted();
    }
    }

    If we combine this examples and try to scale them the result will be a big amount of spread and tangled code. So we need to find a way to generalize the management of computations which are combination of asynchronous operations.

    Tasks in GuggaFF

    The base unit for solving these kind of problems in GuggaFF is the task. The task is abstraction of operation which has determined begin and end. It is represented by the interface gugga.common.ITask.

    In GuggaFF we have a lot of implementations of this interface – ImageLoder, XMLLoader, TimelineAnimation, PropertiesTweenAnimation. Also we provide some helper tasks which simplify and reduce the resulting code in this approach – ExecuteMethodTask, ExecuteAsynchMethodTask, SingleExecutionTask.

    So once we have tasks we need a way for combining them. The basic composition of tasks is the linear sequence:





    This composition can be implemented with the gugga.sequence.TaskSequence class. It uses an single-linked list for managing the task execution. As we have in the Composite design pattern TaskSequence is also task. When we start the sequence, the head of the list is stated too. Every task in the list waits for the end of his predecessor and then it is started. This iteration continues until the last task in the sequence has been completed, then the whole sequence completes.

    If we rewrite the previously mentioned example of sequence of animations with the TaskSequence class it will look like:
    private var mAnimation1 : IAnimation;
    private var mAnimation2 : IAnimation;
    private var mAnimation3 : IAnimation;

    private function startAnimationsSequence() : Void
    {
    var animationSequence : TaskSequence = new TaskSequence();
    animationSequence.addTask(mAnimation1);
    animationSequence.addTask(mAnimation2);
    animationSequence.addTask(mAnimation3);

    Listener.createSingleTimeListener(
    new EventDescriptor(animationSequence, "completed"), Delegate.create(this, onAnimationSequenceCompleted));

    animationSequence.start();
    }

    private function onAnimationSequenceCompleted() : Void
    {
    //do something (ex. notify for the completion of the sequence)
    }


    Before describing the other composite task in GuggaFF – gugga.sequence.TaskManager we will need to introduce the abstraction for precondition.

    In GuggaFF it is abstracted by the gugga.common.EventDescriptor class. This class is a pair of event name and an object which raises this event. So the EventDescriptor class exactly describes a moment in the lifetime of concrete object.

    GuggaFF provides a mechanism for composing preconditions with the gugga.sequence.PreconditionsManager class. This manager observes a collection of preconditions and raises an event when all of them are met.

    If we use PreconditionsManger in the example of waiting for completion of two loaders it will be something like:
    private var mImageLoader1 : ImageLoader;
    private var mImageLoader2 : ImageLoader;

    private function setConent(aUrl1 : String, aUrl2 : String) : Void
    {
    var preconditionManager : PreconditionsManager = new PreconditionsManager();
    preconditionManager.add(new EventDescriptor(mImageLoader1, "completed"));
    preconditionManager.add(new EventDescriptor(mImageLoader2, "completed"));

    Listener.createSingleTimeListener(
    new EventDescriptor(preconditionManager, "preconditionsMet"), Delegate.create(this, onImageLoadersCompleted));

    mImageLoader1.load(aUrl1);
    mImageLoader2.load(aUrl2);
    }

    private function onImageLoadersCompleted() : Void
    {
    //do something (ex. start reveal animation)
    }


    When we have the idea for precondition, we can easily describe the TaskManager class as a composite task which manages the execution of its children by preconditions. We can think that the TaskManager is a web of tasks connected by preconditions.



    According to Composite Pattern, the TaskManager is task itself. When the manager is started, all of its starting tasks are started too. When all the preconditions for certain task in the web are met and all of his predecessors are completed then the task is started. The manager is completed when all final tasks are completed and all final precondition are met.

    As you see TaskManager lets you to solve complex situations which are combination of all previously mentioned common problems. A simple example of his usage can be illustrated by extending the example for usage of PreconditionManager by adding an animation which should be started after completion of the loaders. So the resulting code will be:
    private var mImageLoader1 : ImageLoader;
    private var mImageLoader2 : ImageLoader;
    private var mAnimation : IAnimation;

    private function setContent(aUrl1 : String, aUrl2 : String) : Void
    {
    var taskManager : TaskManager = new TaskManager();
    taskManager.addStartingTasks([mImageLoader1, mImageLoader2]);
    taskManager.addTaskWithPredecessors(mAnimation, [mImageLoader1, mImageLoader2]);
    taskManager.setFinalTask(mAnimation);

    Listener.createSingleTimeListener(
    new EventDescriptor(taskManager, "completed"), Delegate.create(this, onTaskManagerCompleted));

    taskManager.start();
    }

    private function onTaskManagerCompleted() : Void
    {
    //do something (ex. notify for the completion)
    }


    Stay tuned for more articles related to interruption of tasks, deeper look into web of tasks (TaskManager) and more advanced techniques related to their usage.

    Wednesday, September 27, 2006

    Application Building Blocks part 2 - Commands

    Leveraging the browser back and forward functionality in Flash using Commands and the Gugga Flash Framework

    With this new posting we would like to introduce one more of the key aspects used in the Gugga Flash Framework, the Commands, along with a real world example how to apply them. As a wide aspect framework GUGGAFF takes advantage of this well known concept in software development to introduce some key features. Commands' sole purpose is to abstract requests and encapsulate their logic. They decouple the caller from the callee, allowing undoable actions and preprocessing.
    We will show you how you can apply that to manage the browser history functionality in a Flash application, or in more familiar terms the browser back and forward buttons. Although there are already examples of such implementations most of what we seen is for applications build using frame based approach. But what happens when you do not have frames and you want to build a flash application using OO methodology? The need to persist application state, ability to buffer what the user does with your application and restore that state.

    Command Pattern

    We are not going to lay out in detail what the command pattern is all about but for the sake of context and explanations how we applied it in GuggaFF here is a brief layout:
    „Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request....
    The Command pattern lets objects make requests of unspecified application objects by turning the request itself into an object. This object can be stored and passed around like other objects. The key to this pattern is an abstract Command class, which declares an interface for executing operations. In the simplest form this interface includes an abstract Execute operation. Concrete Command subclasses specify a receiver-action pair by storing the receiver as an instance variable and by implementing Execute to invoke the request. The receiver has the knowledge required to carry out the request...“



    GuggaFF and Commands

    In GUGGAFF the Commands primary usage is to abstract navigational requests. A navigation request might imply a various expected results: opening or closing a secton, a popup, following a deep link or cross section navigation, position a component in a state.
    When you build an application with GUGGAFF, you can base the navigation architecture of your application on commands for navigating through the Sections or inside components.

    The Benefits

  • Using commands allows us to abstract the invoker of a navigation requests from the receiver.
  • We are also able to maintain a command history buffer , which helps us to support browser history events such as back and forward.

    Key Players and their responsibilities

    There are several key players in the framework that cooperate using commands.

  • MenuItemsController, responsible for execution of NavigationCommands in response to user activities with your application's navigation menu. It is the invoker from the diagram above.

  • NavigationCommand, a specific command implementation possesing enough information to navigate through the application.
  • OpenPopupCommand, another implementation of command used for opening popup within your application

  • CommandManager , a singleton responsible for executing commands without being aware of their specific implementations since they expose the command interface. It also acts as a history buffer, but we will get to that later.

  • Application, a command receiver for NavigationCommands, available through the IApplicationCommandReceiver interface.


  • How does it all work?


    We have already made a brief lay out of the command pattern and also identified the key players participating. Here is a more detailed explanation about the players in the GuggaFF and how they cooperate.

    The Application class was identified as the command receiver for navigation requests, and it should provide the IApplicationCommandReceiver interface to the commands. The interface defines methods for:

    1. Navigating inside the application using a given Section Path (a dot notation of sections or components hierarchy describing it uniquely)
    We would expect the commands in our history buffer to be able to reverse the application state. Considering that the application also exposes the following methods :

    2.Creating navigation state (Memento Desing pattern) preserving the current navigation Path.

    3.Setting navigation state to a previously preserved one

    A MenuItemsController in our application acts as an invoker for commands. To ensure the invokation, we equipe the controller with commands for the items it aggregates. It is usually done durring the initialization of the controller.

    To maintain a history buffer, the MenuItemsController delegates the command execution to the CommandManager singletone. Once the execution is delegated to him, the command is stored in the buffer and processed.
    The CommandManager also needs to be able to reverse the application state. Reversing of the application state is available calling the manager, to navigate to a particular command in its buffer. To identify the command in the buffer we use a command index. A command index should be remembered whenever we want to be able to reverse to a state.

    This ability to reverse state forces the commands to create and store a navigation state memento right before their execution.

    The next aspect is how the command pattern implemented within the framework gives us the ability to manage the browser history back and forward.

    Real world example of managing browser history back and forward

    Solution architecture

    The first issue we face when building a solution to manage browser back and forward buttons is the fact that the browser history buffer is not affected when the flash application is navigated. A way to solve this problem, is to issue parallel requests to the browser, every time the application is navigated, and it is also an important point that these requests should not cause reload of the flash movie. To do that, we choose to update the hash of the browser address bar.

    Once we are able to use the browser buttons, we would expect them to reverse the application to a previous navigational state. In order to do that, our application is forced to maintain its own history buffer for navigational states.
    It should meet the following requirements

    1.Navigational requests should be abstracted so the history buffer can work with them
    2.The history buffer should be able to reverse the application state using the stored requests

    To meet the requirements we abstract navigational requests into commands and store them into the history buffer. The commands also might be undone or re-executed later to reverse the application state.

    Once we have the commands we should put them together with the items in the browser history, which we do by passing a command identifier to the address bar hash. Given that we are able to reverse the application navigational state when the browser history is navigated.

    In addition to the previously mentioned key players we also:

    1.Need a class abstracting the communication with the address bar. This is the AddressBar.
    2.And a class maintaining the communication between the AddressBar and the CommandManager. This is the AddressBarManager.


    The following sequence diagram illustrates the interactions between the participants in our solution.




    [DOWNLOAD]

    You can test the application here:
    History Management Sample App

    You can download the sample application from here:

    HistoryManagement.zip

    Wednesday, September 20, 2006

    Why a new Flash Framework?

    Flash as a technology besides its obvious benefits and capabilities posses greater then other technologies challenges related to work flow , separation of code and design , development environment, process, maintenance, extensibility and reusability of concepts and code.
    Most of the developers working with flash and creating web sites do not use OO programming and design patterns.90% of them are single developers not teams and they consider this an overhead. The methodology and approach used in other technologies are not applied in Flash only in Flex and other frameworks that are build around creating applications not web sites in Flash.
    Let's look at the available options for building OO, extensible , maintainable flash based web sites. There are a number of frameworks most of which focus on applications(Flex, Cairngorn, ARP). At the same time most of the web sites build using Flash are multi page web sites. Someone can argue that application frameworks can be used to build sites but in fact the requirements are so different that this is yet to be proved that is has an economic value to it.
    Let's add to this mixture one more critical element, the creative one.Each web site strived to be very unique in terms of look, feel and interactions.

    So a flash developer/team is under gun to create a unique look and feel, very highly interactive, performing, web site under tight deadline. Add to that you want to be able to reuse your code, concepts, architecture. Implement the site in a way that a year from now you can still read and extend your code and the requirements just hit the sealing. If this is not enough, you as a developer do not have the proper development environment, debugging and testing tools and frameworks.Or is it so ...Off course we will not address all these issues in one article but we will start taking care of those one by one.

    We are not going to list all problems related to developing web sites with Flash but to quote Jesse Warden from one of his posts there are 4 key problem with Flash Development:
    # Deadline - all projects are under tight dealdline which imposes requirements for how quickly can you pull a project
    # Creative - you cannot pose any creative restrictions upfront to the designers and IA
    # Bandwidth - you must employee as little as possible resources
    # Maintainability - you have to be able to extend every web site you have ever build no matter how much time it went by and make it quick

    Let's add to that list a bit more spice and what we want to be able to do with Flash from a Software Development Perspective:
    # write in OO manner in Flash
    # use Design Patterns in Flash
    # create maintainable, extensible data aware multi tier web sites in Flash

    I believe we owe you one more definition and an explanation, why do we think we have a framework and the best explanation we found is in one of the famous Design Paterns Books:
    "A framework is a set of cooperating classes that make up a reusable design for a specific class of software... You customize a framework to a particular application by creating application-specific subclasses of abstract classes from the framework.

    The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately...

    Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent to their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you...

    Frameworks are becoming increasingly common and important. They are the way that object-oriented systems achieve the most reuse. Larger object-oriented applications will end up consisting of layers of frameworks that cooperate with each other. Most of the design and code in the application will come from or be influenced by the frameworks it uses."

    We could not put it better not only in terms of what we are expecting of a framework but what we actually are offering and we can only encourage you to explore Gugga Flash Framework. I'm sure it has room to be extended and improved but we believe there is a very good foundation proved to work in a large number of real work projects.