The metadata processor I've created is called URLMapping which allows you to easily map URLs to methods. Here's a simple example:

[URLMapping( url="/helloWorld" )]
public function sayHelloWorld():void
{
model.msg = "Hello world!";
}

The URL Mapping processor will automatically start listening for URL changes. For the above example, any time the URL changes to flexapp.html#/helloWorld the sayHelloWorld() method will automatically get called. Also, since url is the default metadata argument, the following example works exactly the same:

[URLMapping( "/helloWorld" )]
public function sayHelloWorld():void
{
model.msg = "Hello world!";
}

You can also use parts of the URL as parameters:

[URLMapping( "/hello/{0}" )]
public function sayHello( name:String ):void
{
model.msg = "Hello " + name + "!";
}

And optionally change the browser window title when the URL changes:

[URLMapping( url="/hello/{0}", title="Hello {0}!" )]
public function sayHello( name:String ):void
{
model.msg = "Hello " + name + "!";
}

Lastly, [URLMapping] also works in reverse with the help of the Swiz [Mediate] metadata. In this example the URL will change to /hello/Ryan and the browser window title to "Hello Ryan!" when the HelloEvent.HELLO event is dispatched:

[URLMapping( url="/hello/{0}", title="Hello {0}!" )]
[Mediate( event="HelloEvent.HELLO", properties="name" )]
public function sayHello( name:String ):void
{
model.msg = "Hello " + name + "!";
}

And then dispatch the event:

<s:TextInput id="nameInput" text="Ryan" />
<s:Button label="Say Hello" click="dispatchEvent( new HelloEvent( HelloEvent.HELLO, nameInput.text ) )" />

[URLMapping] Getting Started Resources

I've created a simple Customer App example, with view source enabled, to show how you could use [URLMapping] in a full application.

• Download the CustomerApp example
• Download Swiz 1.0 Beta
• Download swiz-urlmapping.swc
• Grab the source on Github

Overall I was really happy with how quickly I could get these working with Flex 4. It wasn't quite as painful as I originally thought and I'll discuss the differences below.

View the Example
View the Source Code

ILayoutElement

In Flex 4, UIComponent implements ILayoutElement which provides you a bunch of methods to manage the layout of each child. For 2D layouts you would use element.setLayoutBoundsSize( width, height, postLayoutTransform ) to set the size and element.setLayoutBoundsPosition( x, y, postLayoutTransform ) to set position.

OpenFlux instead allows you to set x, y, width, height, z, rotationX, rotationY, rotationZ directly to a token which is used to animate the child to its new position/size.

Matrix3D

With OpenFlux, you set the z, rotationX, rotationY, rotationZ properties directly. With Flex 4 you instead use element.setLayoutMatrix3D( matrix, postLayoutTransform ). Instead of passing in the above properties it instead expects an instance of Matrix3D. This was my first use of Matrix3D and Vector3D (FP10 classes) and had no idea what I was doing until I looked at the example Flex 4 WheelLayout

A common approach would be to first set the initial 3D coordinates of the child, next apply any rotation and third center the child in the container. Below is the Matrix3D code for AwesomeLayout:

var matrix:Matrix3D = new Matrix3D();
matrix.appendTranslation( elementWidth * -( selectedIndex - i ), elementHeight / 2, 0 );
matrix.appendRotation( Math.abs( selectedIndex - i ) * 2, Vector3D.Y_AXIS );
matrix.appendTranslation( width / 2, height / 2, 0 ); // center element in container
element.setLayoutMatrix3D( matrix, false );

maintainProjectionCenter

FP10 adds a perspectiveProjection property to the Transform class which works similar to a camera in Away3D. By default, the prespectiveProjection is set to the top left but for my layouts I need it to be the center of the container. This is easily done with the following code:

var pp:PerspectiveProjection = new PerspectiveProjection();
pp.projectionCenter = new Point(container.width / 2, container.height / 2);
container.transform.perspectiveProjection = pp;

Since wanting center projection is so common though, Flex 4 made this even easier by adding a maintainProjectionCenter flag to UIComponent. When the layout is attached to a container, I simply override the setter and set this property to true.

layer

Another pain in the butt with FP10 is that the z property has nothing to do with the z-index of the DisplayObject. What that means is even though the DisplayObject appears to be further away and smaller, it will still be in front of closer DisplayObjects unless you update it's position in the display list.

Flex 4 solves this by adding a layer property to UIComponent. For the List component for example, this allows you to specify a different display list index for the item renderer compared to where it is located in the data provider. You simply set the layer property for each element (based on its z property ideally) and if required call container.invalidateLayering()

OpenFlux handles this automatically after the layout is done setting the position of each child.

Animation?

One question I'm hoping someone has a decent answer to is regarding animating the size/position of child elements. For example, if I switch layouts I want the children to be tweened to their new positions. This is easy to do with OpenFlux but I have no idea how to do it with Flex 4. I know Flex 3 introduced a dataChangeEffect but this seems to have disappeared with the Flex 4 List component.

What next?

So, I only implemented the very basics of the layout. Next steps would be to add support for measure, scrolling and virtualization. I've included a LayoutBase3D class which handles common 3D tasks. I'd love to see what layouts others come up with and think it would be cool to start a Flex 4 Layouts open source project.

Feel free to write any questions in the comments.

View the Example
View the Source Code

OpenFlux Application (77KB)

Flex Application with OpenFlux Components (205KB)

I have two applications above that look exactly the same. The difference is one is a OpenFlux application with OpenFlux components and the other is a Flex application with OpenFlux components. Although the code is almost identical, the OpenFlux app compiles to 77kb and the Flex app compiles to 205kb. Before you think "oh great another framework" I'd like to point out the following:

1. OpenFlux components can be used with or without Flex

OpenFlux components all extend a class (currently called PhoenixComponent) that implements IUIComponent allowing them to work with or without Flex. Likewise, you can use Flex classes and projects like Degrafa and Mate with pure OpenFlux applications.

2. This is not a completely separate framework, just lighter weight implementations of Flex's interfaces

We'll continue to use the parts of Flex that work well but replace the parts can be done better. Luckily the Flex team uses interfaces well allowing us to use our own implementations for almost every piece of the framework.

3. MXML, CSS, Resource Bundles and Data Binding all still work with pure OpenFlux apps

These 4 features of Flex make our lives as developers way easier and I wouldn't have even bothered continuing getting OpenFlux independant from Flex if it ment I'd have to build all my applications in pure AS3. Utilizing these features do add size to your compiled application but I think the benefits they provide make it well worth it.

4. Flex is monolitic, OpenFlux is modular.

My opinion is if your application is loaded over the internet it should be highest priority to keep the application size small and don't include any code that you aren't utilizing. For example, the List component in this application doesn't need drag n' drop support so that code isn't included.

Even if create a basic Flex application with just a List component that application's optimized compile size is 250kb. Actually, an OpenFlux application is even smaller then a Flex application that uses Runtime Shared Libraries. I think 77kb even is too large though and it's an on going effort to continue reducing the size of OpenFlux applications.

So what's next?

Our goal is to have an OpenFlux SDK you can use with Flex Builder and an OpenFlux.org website available in time for 360|Flex Indianapolous. I have a session called "OpenFlux and Flex 4" where I will discuss the differences between the two frameworks, give examples on when to use one over the other and how you can use them both together.

Over the last month of coding/experimenting we weren't even sure if our goals were possible. Now that we've been able to accomplish mainly what we hoped for we'll be focusing on resolving issues, documentation and examples.

The best part is 100% of the code from the Tree and DataGrid components were re-used for the TreeDataGrid. In fact, the TreeDataGrid isn't even a separate component, it's just a new view for the regular OpenFlux DataGrid.

I think this really shows off where OpenFlux's architecture shines. Moving the logic in to separate controllers allows you to easily mix and match functionality to build any component you desire quickly. If the Flex SDK was written in a similar way the AdvancedDataGrid wouldn't have had to be written from scratch.

Over the next couple weeks I plan on fixing the remaining issues and at that point I'll switch to blogging on how to use all this new functionality to build some really cool 3D components (OpenFlux/Plexiglass).

Feel free to view the source and post any feedback you have in the comments.

One major plus is how well plugins/extensions play with RoR. My favorite so far is FileColumn, which couldn't compliment RoR any better. With only a couple lines of code I can have photos being uploaded, resized and displayed within my application. The only complaint I had was quickly solved by using ActAsPartitionedId with FileColumn, which I do hope is bundled with FileColumn in the future.

This is also my first experience with Ruby. At first glance the syntax looks a little odd but coming from a perl background, it grew on me quickly. I think this language has a lot of potential and I hope its user base keeps growing.

Repeatedly a lot of my ideas revolve around blogs and I've even been getting multiple requests to build blog hosting software. At the same time I also think about giving back to open source. Lately I have been contributing ports to the DarwinPorts Project.

Although I think MovableType is a great start to a blog manager, it definitely lacks in many areas. For example it could use an easier way to change themes/templates, adding plugins and how you content is displayed. So I am going to write a new blog system, might even name at CyberScript (my company name)

Another reason I have decided on this is because I think releasing software for free would be a great way to really show my talent. I have also seem a lot of companies base their business on open source and find that very respectable. Also free software is a great way to get lots of exposure quickly.

Stay tuned for more details on this project as I get further in to planning.

As a web developer I depend on the system I'm using to work correctly. I have my own code problems to solve and should not have to be creating work arounds or spend hours guessing why my code runs different on every machine I install it on. Some might say suck-it-up but if I'm wasting time on something that could be avoided, why not avoid it? It is unproductive and burns me out for the rest of the day.

Anyways.. enough complaining for today..

Although this is a great system.. One suggestion I would have for the MovableType developers is to explain further on this "entry body/extended entry" stuff. How do I know how much I should write in the entry body? Does the entire entry body get displayed in my RSS feed? I think the extended entry textarea should be hidden by default. Also why not a browser-based wysiwyg editor? That technology has been around for quite a while now.

Anyways.. I think this is a enough for my first post