[lang_en]
Starting a weblog is a good reason for some tidying up ^^.
A few months ago, far from imagine the arrival of the Free Flex SDK, finding an alternative for the as2 mx framework was still a true preoccupation. It is the reason why I took interest in ActionStep.
[/lang_en]

[lang_es]
Abrir este blog es un buen pretexto para revisar y ordenar mis viejas cajas ^^.
Hace algunos meses, lejos de imaginar la llegada del Free Flex SDK, encontrar una alternativa al framework as2 mx era realmente una apuesta vital. Es en relación a esto que me interesé en ActionStep.
[/lang_es]

[lang_en]
What I have to say?

Frankly, Actionstep is a very robust framework, but at this date, one can only question oneself about its place and future. The Roadmap blew up and the announce a few months ago of a free Flex framework let an interrogation.

UPDATE (17.05.06):
Hopefully my fears were only fears. ActionStep stays on the rails !

As of alpha 1 version, I immediately started to test.
Flash Remoting adept since the first days, I was looking, in addition, for an Open Source Remoting API alternative. Thanks to great exchanges with Ray Chuan I was able to use ASRemoting in production very early (the package is available as a standalone library). As most of my projects are ARP-based, the first obvious test was to port Pizzaservice to ActionStep.

I will not speak about the ActionStep API in details, it is not my point.
I will discuss, nevertheless, about a fundamental specificity of its internal workings which led me to use a legitimate hack to make it compatible with ARP.

The expression “legitimate hack” is not hazardous:

- Hack, because ActionStep is itself a structural framework.
- Legitimate, because ActionStep is very well-designed and offers a lot of possibilities.

An “ActionStep/ARP combo” looks a rather absurd idea whose realization seems compromised enough. In particular, for the following reasons:

- ActionStep prevents us from dealing directly with MovieClips, encapsulating this management in a hierarchy of View relations.
- The views depend on a super view (instantiated by NSWindow) hardwired to _root.
- Like above-mentioned, Actionstep is also an application framework conceived to initialize at the base of the project (NSapplication).

[as]
public function init()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRect(
new NSRect(0,0,500,400));
var view1:NSView = (new NSView()).initWithFrame(
new NSRect(50,50,400,300));

window.setContentView(view1);

// Some UI instantiation later…
view1.addSubview(ASLabel);
view1.addSubview(NSStepper);

// Start the mug…
app.run();
}
[/as]

So, how we make it? It’s not that complicated.

The NSWindow class allows to load different types of super View. If I simplify, the super view can be:

- an external SWF
- instances of window.ASRootWindowView

You surely got it, the solution consists in subclassing ASRootWindowView and give our custom super view a method to reparent the MovieClip target.

[as]
class org.actionstep.window.ASClipWindowView
extends org.actionstep.window.ASRootWindowView
{
public function ASClipWindowView() {
super();
}

public function changeRoot(target:MovieClip) {
WINDOW_CLIP = target
}
}
[/as]

[as]
// org.osflash.pizza.view.NavigationForm

import org.actionstep.window.ASClipWindowView;
import org.actionstep.*;

// …

public function initialize()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRectViewClass(
new NSRect(0,0,165,25), ASClipWindowView );

ASClipWindowView(window.rootView()).changeRoot(this);

var view:NSView = NSView((new NSView()).initWithFrame(
new NSRect(0, 0, 165, 25)));

window.setContentView(view);

// …

// Start the mug…
app.run()
}
[/as]

Its a kind of composition where each form instantiates its own NSApplication.

Put aside the gradient header and the transitions, all is work of ActionStep.

There is still a lot to say, especially about ASRemoting. In a next post I will describe how ASResponse & ASRecordset handle remoting results and underline the difference of implementation in ServiceLocator and the CommandTemplate subclasses.

Let’s speak about what is not ActionStep in this version.

Building pizzaService without the support of any FLA was a condition and did not suppose any major challenge. Font embedding wasn’t an issue either. The difficulty rised when I choose the option to dynamically load the fonts. I had to face the plague of sharedfonts.
The solution comes from a suggestion from Chris Bare on the SWFMILL mailing-list. A solution that consists in what himself would name an “educational analysis”. A big thank to him for its invaluable tip.

Here thus, the navigation of our OSFlash pizzaService with NSButton dynamically stylized.

For the Tween effects I preferred the transitions package of Pixlib.
If you do not know this fantastic generic framework, then go discover it. It is a swiss army knife. I cannot live without it anymore !.
For example, with modest applications, ARP seems sometimes too heavy for me, in such cases I use Pixlib’s MVC.

Let’ s return to the transitions:

Changes are very simple :

[as]
import mx.transitions.*
var t:Tween = new Tween(target, “prop”, pennerEasing, begin, finish, duration, useSeconds);
[/as]

with Pixlib
[as]
import com.bourre.transitions.*;
var t:BasicTweenFPS = (new BasicTweenFPS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
or
var t:BasicTweenMS = (new BasicTweenMS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
[/as]

Do not forget to download and place in your classPath the Penner’s equations if you do not have them already.

EventDispatching

Finally, our pizzaService needs one last thing to deserve its OSFlash label: to free itself from EventDispatcher.
Pixlib ‘s EventBroadcaster thus comes to replace it (in a completely polymorphic way).

I will stop there. You will learn more by yourself examining the sources.
Note that you can also start exploring the online demo with Xray (the pizza is delivered with its connector ^^).

Once again it was only a laboratory experiment. Not very polished. Moreover the revision I used is outdated (February, if I remember), so careful if you try to compile with the latest sources from the svn. It could may not work.

The project was developed using FlashDevelop. Grateful thanks to the FD team for their amazing work!

Thank you to read this first ticket.
[/lang_en]

[lang_fr]
Que puis-j’en dire ?

Franchement, ce n’est pas sa robustesse qui lui fait défaut, mais au jour d’aujourd’hui, on ne peut que se questionner sur sa place et son devenir.
Le Roadmap a complètement explosé et l’annonce il y a quelques mois du Flex framework posa l’ intérrogation

Dès la sortie de la version alpha, j’avais donc commencé à experimenter un peu.
Flash Remotien convaincu, je cherchais par ailleurs une alternative à l’ implémentation remoting d’ Adobe.
De fructueux échanges avec Ray Chuan m’ ont permis d’utiliser l’ ASRemoting très tôt en production car la librarie est disponible de façon autonome, chargeable ala DLL.

La majorité de mes projets reposant sur ARP, un premier test tout indiqué était le portage de Pizzaservice.

Je ne vais pas rentrer dans le détail de l’API, ce n’est pas mon propos.

Je parlerai néanmoins d’une spécificité fondamentale des rouages d’ ActionStep qui m’a conduit à employer un hack (tout à fait legitime) pour le rendre compatible ARP.

L’ expression “hack legitime” n’est pas hasardeuse:

- Hack, car ActionStep est déjà en soi un framework structurel.
- Légitime, car ses auteurs ont pensé à laisser des portes ouvertes.

Intégrer ActionStep et ARP est une idée plutôt saugrenue dont la réalisation semble assez compromise. En particulier, pour les raisons suivantes:

- ActionStep nous protège de la manipulation directe des Movieclips, encapsulant cette gestion dans une hiérarchie de type View.
- Les views dépendent d’une view principale (instanciée par NSWindow) dont la référence MovieClip de base a été codée en dur et n’est autre que _root.
- Comme sus-mentionné, Actionstep est aussi un framework de type applicatif, et à priori conçu pour s’initialiser à la racine de votre project (NSapplication).

[as]
public function init()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRect(
new NSRect(0,0,500,400));
var view1:NSView = (new NSView()).initWithFrame(
new NSRect(50,50,400,300));

window.setContentView(view1);

// Some UI instantiation later…
view1.addSubview(ASLabel);
view1.addSubview(NSStepper);

// Start the mug…
app.run();
}
[/as]
Comment faire? C’est plus simple qu’il n’y paraît…

La classe NSWindow contemple la possibilité de charger différents types de view principale. Si je simplifie, la view principale est:

- soit issue d’une source externe (chargement SWF).
- soit la view par défaut, de type ASRootWindowView.

De type ? . Eh oui ^^. Vous l’aurez compris, la solution consiste à offrir à NSWindow une view custom où la cible MovieClip sur laquelle s’initie l’application sera de notre choix.

[as]
class org.actionstep.window.ASClipWindowView
extends org.actionstep.window.ASRootWindowView
{
public function ASClipWindowView() {
super();
}

public function changeRoot(target:MovieClip) {
WINDOW_CLIP = target
}
}
[/as]

[as]
// org.osflash.pizza.view.NavigationForm

import org.actionstep.window.ASClipWindowView;
import org.actionstep.*;

// …

public function initialize()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRectViewClass(
new NSRect(0,0,165,25), ASClipWindowView );

ASClipWindowView(window.rootView()).changeRoot(this);

var view:NSView = NSView((new NSView()).initWithFrame(
new NSRect(0, 0, 165, 25)));

window.setContentView(view);

// …

// Start the mug…
app.run()
}
[/as]

On peut voir ça comme une composition où chaque ArpForm va instancier une NSApplication depuis la méthode initialize().

Mis à part le gradient header et les transitions, tout est oeuvre d’ActionStep.

J’aurais encore beaucoup à dire, notamment concernant sa librairie Remoting.
Ce sera le sujet d’un prochain post où je compte présenter différentes façons de charger en DLL, décortiquer l’ASResponse (equivalent du ResultEvent) et l’ ASRecordSet, et souligner la différence d’implémentation dans le ServiceLocator et les sous-classes CommandTemplate.

Parlons maintenant de ce qui n’est pas ActionStep.

Reconstruire pizzaService sans support de fichier FLA était pour moi une condition et ne supposait aucun défi majeur. Embarquer des polices ne présentait pas plus de difficulté. La problématique se posa néanmoins à l’heure d’opter pour le chargement des polices en externe. Là, je me retrouvais de nouveau confronté au supplice des librairies partagées.
La solution vînt d’une suggestion que me fit Chris Bare sur la mailing-list de SWFMILL.
Une solution passant par ce que lui même n’ hésite pas à nommer une “analyse éducative”. Big thank to him for this invaluable tip.

Voici donc la navigation de notre open source pizzaService pourvu de NSButton dynamiquement stylisé.

Pour les effets de Tween j’ai préféré le package transitions de Pixlib.
Si vous ne connaissez pas encore ce fantastique framework polyvalent, allez tout de suite le découvrir. C’est un vrai couteau-suisse. C’est simple, je ne peux plus m’en passer ^^.

Petite parenthèse à propos de Pixlib (Je lui consacrerai plusieurs tickets).
Personnellement, quand ARP me semble parfois surchargé pour certains types d’applications, je lui préfère généralement le package MVC de Pixlib.

Revenons aux transitions…
Le portage est vraiment très simple:

[as]
import mx.transitions.*;
var t:Tween = new Tween(
target, “prop”, pennerEasing, begin, finish, duration, useSeconds);
[/as]
avec Pixlib
[as]
import com.bourre.transitions.*
var t:BasicTweenFPS = (new BasicTweenFPS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
or
var t:BasicTweenMS = (new BasicTweenMS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
[/as]

N’oubliez pas de télécharger et placer dans votre classPath les équations de Penner si vous ne les avez pas déjà .

EventDispatching

Finalement, il ne manque qu’une seule chose à notre service de pizza pour meriter son label OSFlash: s’ affranchir de l’ EventDispatcher.
La classe EventBroadcaster de Pixlib vient donc le remplacer (de façon totalement polymorphique). Quand je vous dis que Pixlib couvre tous les besoins…

Je vais m’arreter là. Vous en apprendrez davantage par vous mêmes en examinant les sources.
A noter que vous pouvez aussi commencer par explorer l’application en ligne avec Xray (la pizza est livrée avec son connector ^^).

Encore une fois ce n’ était qu’une expérience de laboratoire. De plus la révision qui m’a servi est relativement ancienne. Ne soyez donc pas étonnés si la compilation échoue avec la dernière révision.

Le projet à été developpé avec FlashDevelop. J’en profite pour saluer l’equipe de FD et féliciter leur formidable travail!

Merci d’avoir lu ce premier vrai billet .

[lang_es]
¿Que puedo decir de ello?

Francamente, no es que le falte robustez, pero a día de hoy, tan sólo podemos preguntarnos sobre su lugar y su futuro.
El Roadmap ha reventado completamente y el anuncio hace algunos meses del Flex framework ha puesto la cuestión

Desde la salida de la versión alfa, había comenzado a experimentar un poco.
Flash Remotero de toda la vida, buscaba además una versión alternativa al paquete remoting de Adobe.
Mis fructíferos intercambios con Ray Chuan me han pertimido usar muy pronto el ASRemoting para la producción dado que la librería está disponible de manera independiente cargable ala DLL.

Estando apoyados la mayoría de mis proyectos en ARP, un primer test obvio era llevar Pizzaservice a ActionStep.

No entraré en el detalle del API, no es mi intención.

Hablaré sin embargo de una especificidad fundamental en el funcionamiento interno de ActionStep que me condujo a emplear un hack (totalmente legítimo) para hacerlo compatible con ARP.
El término “hack legítimo” no es casual:

- “Hack” porque ActionStep es ya, por sí mismo, un framework estructural.
- “Legítimo”, ya que sus autores han pensando en dejar las puertas abiertas.

Integrar ActionStep y ARP es pues una idea más bien descabellada cuya realización parece bastante comprometida. En particular, por las razones siguientes:

- ActionStep nos protege de la manipulación directa de los MovieClips, encapsulando esta gestión en una jeraquía de tipo view.
- Los views dependen de una view principal (instanciada por NSWindow) cuya referencia MovieClip de base ha sido “hardcoded” y no es otra que _root.
- Como ya he dicho antes, Actionstep es tambíen un framework de tipo aplicativo y a priori concebido para inicializarse en la raíz del proyecto (NSapplication).

[as]
public function init()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRect(
new NSRect(0,0,500,400));
var view1:NSView = (new NSView()).initWithFrame(
new NSRect(50,50,400,300));

window.setContentView(view1);

// Some UI instantiation later…
view1.addSubview(ASLabel);
view1.addSubview(NSStepper);

// Start the mug…
app.run();
}
[/as]
¿Cómo hacer, pues? Es más simple de lo que parece.

La clase NSWindow contempla la posibilidad de cargar diferentes tipos de view principal. Simplificando, la view principal es:

- o bien de origen externo (cargando un SWF)
- o bien la view por defecto, de tipo ASRootWindowView.

¿”de tipo” ? . Pues sí^^. Como ya habráis comprendido, la solución consiste en dar a NSWindow una view customizada donde el MovieClip en el cual se inicia la aplicación será de nuestra elección.

[as]
class org.actionstep.window.ASClipWindowView
extends org.actionstep.window.ASRootWindowView
{
public function ASClipWindowView() {
super();
}

public function changeRoot(target:MovieClip) {
WINDOW_CLIP = target
}
}
[/as]

[as]
// org.osflash.pizza.view.NavigationForm

import org.actionstep.window.ASClipWindowView;
import org.actionstep.*;

// …

public function initialize()
{
var app:NSApplication = NSApplication.sharedApplication();

var window:NSWindow = (new NSWindow()).initWithContentRectViewClass(
new NSRect(0,0,165,25), ASClipWindowView );

ASClipWindowView(window.rootView()).changeRoot(this);

var view:NSView = NSView((new NSView()).initWithFrame(
new NSRect(0, 0, 165, 25)));

window.setContentView(view);

// …

// Start the mug…
app.run()
}
[/as]

Podemos ver esto como una “composición” donde cada ArpForm va a instanciar una NSApplication desde el metodo initialize().

Aparte del “gradient header” y de las “transiciones”, todo es obra de ActionStep.

Tendría mucho que decir aún, sobre todo concerniente a su librería Remoting.
Será el tema de un próximo artículo donde cuento con presentar diferentes maneras de cargar en DLL, desmenuzar el ASResponse (equivalente del ResultEvent) y el ASRecordSet, y subrayar la diferencia de implementación en el ServiceLocator y las subclases CommandTemplate.

Hablemos ahora de lo que no es ActionStep.

Reconstruir pizzaService sin soporte de un fichero FLA era para mí una condición y no suponía ningún desafío mayor. Importar fuentes no presentaba tampoco más dificultad.
La problemática surgió sin embargo a la hora de optar por cargar dinámicamente las fuentes. Ahí me encontré confrontado de nuevo al suplicio de las librerías compartidas.

La solución vino de una sugerencia que me hizo Chris Bare en la mailing-list de SWFMILL.
Una solución que pasa por lo que el mismo no duda en llamar un “analisis educativo”. Big thank to him for this invaluable tip.

He aquí, pues, la navegación de nuestro open source pizzaService con NSButtons de estilo determinado dinámicamente.

Para los efectos “Tween”, he preferido el paquete transitions de Pixlib.
Si no conocáis aún este fantástico framework polivalente, id enseguida a descubrirlo. Es una verdadera navaja suiza. Simplemente, ya no puedo pasarme sin ella ^^.

Pequeño paréntesis sobre Pixlib.
Le dedicaré varios tópicos, incluso puede que el siguiente.
Personalmente, cuando ARP me parece a veces sobrecargado para ciertos tipos de aplicaciones, generalmente prefiero en su lugar el paquete MVC de Pixlib.

Volvamos a las “transiciones”…
El cambio es realmente muy simple:

[as]
import mx.transitions.*
var t:Tween = new Tween(
target, “prop”, pennerEasing, begin, finish, duration, useSeconds);
[/as]

avec Pixlib
[as]
import com.bourre.transitions.*;
var t:BasicTweenFPS = (new BasicTweenFPS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
or
var t:BasicTweenMS = (new BasicTweenMS(
target, “prop”, finish, duration, begin, pennerEasing)).execute();
[/as]

No olvidáis descargar y poner en su classPath las ecuaciones de Penner si no las tenéis ya.

EventDispatching

Finalmente, tan sólo falta una cosa a nuestro servicio de pizza para merecer su sello OSFlash: liberarse del EventDispatcher.
La clase EventBroadcaster de Pixlib viene pues a reemplazarlo (de manera totalmente polimorfica). Cuando os digo que Pixlib cubre todas las necesidades…

Voy a dejarlo aquí. Aprenderéis más por vosotros mismos examinando las fuentes.
Notad que podéis también empezar por explorar la aplicación aquí con Xray (la pizza se entrega con su conector ^^)

Una vez más, tan sólo era un experimento de laboratorio. Además la revisión que usé es relativamente antigua (mes de Febrero, creo). No os sorprendáis, pues, si vuestra compilación falla con la ultima revisión.

El proyecto ha sido desarollado con FlashDevelop. Aprovecho para saludar al equipo de FD y felicitar su formidable labor!

Gracias por haber leído este primer post de verdad .
[/lang_es]