Français

Translate original post with Google Translate

Let’s sum up the many faces of sharedfonts with swfmill.

Sharing one font per swf:

CommandLine :
swfmill simple "src/georgia.xml" "deploy/Georgia Gras.swf"

if we do so, we access the font by its default name:

Because we didn’t give the font any name in particular in the configuration file, the embedded font is identified by its Digital Signature.

In case we want to specify a name:

We then refer the font as follow:

There are advantages to specify a custom name.

- to import various styles in one go:

We have then free hand to use the style we want:

- It's very handy if we deal with differents weights by classifying them semantically:

Finally it's up to you to decide how to handle the build:

Personally, I use a batch process, like so:

Okay, that's all folks!
You will learn more from the source files where you'll find:

- the TTF/ XML assets' directory structure inside sharedfontBuilder;) folder.
- the source .as files (Application and TextFormatCellRenderer classes).

--------------------------------------------------------------------------------

A few words about the application example

- Datagrid instantiation and cellRenderer linkage were all done in Fla. ActionScript was injected later with MTASC.

- I used Pixlib's XMLToObject and Libstack/GraphicLib to handle the fonts loading process (I LOVE Pixlib, everybody should know from now ^^).

Enjoy!

Français

Translate original post with Google Translate

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.

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).

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.

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 :

with Pixlib

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.