The new Minor(major) 0.9.2 release of Gugga Flash Framework

[sotirov....@gmail.com]

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.
http://www.gugga.com/GuggaFlashFramework/

[Todor Kolev]

MX Delegate is just what we want - a delegate. Maybe we will replace it with a Gugga Delegate in the next release but this will be just to be fully separated from MX, not because we will provide some much better implementation.

On 5/16/07, R.A. Williamson <action...@gmail.com> wrote:

Just curious why you're still using the MX Delegate?
-rw

[sotirov....@gmail.com]

Would you care to create an implementation for GuggaFF and submit it
for review and inclusion in the framework?

[Todor Kolev]

We are very happy to have you contributing to GuggaFF. Currently GuggaFF is designed to treat delegates as pointers to functions. Our classes such as ExecuteMethodTask are designed to take method arguments separately from the delegate function. This is because in future versions we plan to have lazy evaluation of these arguments.

For now we don't want to mess delegates in terms of function pointers with the arguments of the function. This can lead to confusion when delegate with arguments in it is supplied to an ExecuteMethodTask. We suggest you to implement just a simple delegate, with no arguments contained in it. In future versions of GuggaFF the extended capabilities can be added if they become compatible with the other conceptions in the framework.

The general requirement for your implementation is to have maximum performance.

To keep the framework consistent, we'll suggest you to use the same naming convention as the other parts of the framework:

- function argument start with prefix "a" ( aArgument )
- local variables are camelCase ( localVariable )
- private variables start with prefix "m" ( mPrivateVariable )
- public variables are without prefix ( PublicVariable )
- constants are all caps ( MY_CONSTANT )
- functions are calelCase ( myFunction )

On 5/17/07, action...@gmail.com <action...@gmail.com> wrote:

Absolutely. I'll get right on that
-rw