Despite being an Adobe fanboy, I never cared much for how the Spry framework handles things like animations. Seemed complex at the time for basic operations. At work, they have standardized on using the YUI framework. This has been great for me because I have always wanted to dive deeper into it and learn about its ins and outs. With that, I needed to do some basic fade animations for a User Interface I am working on.

I looked up the docs for the the animation package. After reading for a few minutes, I was blown away at how the YUI developers were able to execute such a powerful, customizable feature in a very simple way. First, you simply create an attributes object that contains the property you want to change (in our case it will be the opacity) and what you want to change it to:

Notice that a from attribute is not present. This is only because if from is not provided, YUI will perform the animation based on the current value of the attribute you are modifying.

Once you have your attributes object defined, animating your object is simple:

We instantiated a new Anim object by passing in a string of the id of the element we want to animate (note: a dom element object can also be passed), and the attributes object. Then we simply call the animate() method to play the animation.

Extremely simple and straightforward. On top of this, YUI, having the incredible event engine that it has, allows you to subscribe to events for onStart, onTween (which occurs on every frame), and onComplete providing limitless animation effects and chaining.

Be sure that when you try the examples above, that you have included the following files in your document head:

Finally, you must also create an element that you actually want to apply the animation with an id of "myDiv" for the above examples to work.

I started a project a couple of months ago that has and is going to continually have a very complex and growing architecture. The technology stack in place is Flex 3, Cairngorm 2.2, ColdFusion 8, ColdSpring, Transfer, and SQL Server 2005. This is my first Flex application that will be using Transfer to handle the database abstraction layer. Normally, I would use Brian Rinadi's Illudium PU-36 CFCGenerator to handle the initial generation of all my CFCs and from there would either modify the XSLT files or simply append to the generated CFCs as I saw fit.

The problem with this type of approach lies namely in the early stages of application design and development (especially since I traditionally don't go through a line of specs working on a solo project) when the database is going through many changes. Each time you make a change to the database, you either have to regenerate your files which will overwrite any changes you made, or you have to manually hand-code the database changes. On top of this, it doesn't take care of any of your table relationships as per a 3rd normal form database structure. You then have to design your own home-brew setup of such a system if you require it, or simply provide functions that return the structs/VOs to Flex as you need them by manually building up the hierarchical tree of the model.

For this project, I knew from the beginning that the database schema was going to be pretty complex and that it was also going to be going through changes as I developed and tried things out. I knew that I wanted to get Transfer to work with Flex. I had tried this once in the past and failed because I was designing Flex applications differently at that time. I now know better to design with a service layer in mind.

Although, it is not that easy either. There are actually quite a few steps involved when using Transfer to interact with your database and to return the right kind of objects back to Flex. Also, let me state, that I am talking about this in terms of using the AMF protocol with RemoteObjects between ColdFusion and Flex so that datatypes are appropriately and quickly translated.

This post will first introduce the Transfer ORM framework and why it is not a basic task to integrate it into your ColdFusion / Flex application. In the next part of this article, I will discuss the technical details of getting this all to work.

Transfer ORM framework

ORM, or Object-Relational Mapping, in simplistic terms is abstracting a representation of your data inside a database as objects in your application. An ORM framework does all of this abstraction semi-automatically by means of introspection to your database and generating the necessary files, or by a configuration file that describes the datatypes and the relationships of the tables to each other. Transfer falls into the latter category.

While some say that a fault of Transfer (esp when compared to a competing framework, Reactor) is that you have to write the table structure and it's relationships manually in an XML file. Whereas Reactor is a framework that reads the database metadata. At first, I thought this same thing and after working with Transfer later, have found it much better to be in control and to define the relationships myself. With this method I really feel like I have a much better understanding of what Transfer is creating when it generates it's objects. Plus when debugging your code it is easier to see what columns/fields are causing issues in your relationships.

The benefits of using Transfer over generating the CFCs yourself using tools like Brian Rinaldi's Illudium PU-36 CFCGenerator is that once you have defined your XML file, the actual creation of the CFCs is completely automatic. To give you an example, let's say you have a table in your database called Employee that has the following fields: employeeId, firstName, lastName, email. Once you have instantiated the TransferFactory, you simply call the object the you would any other VO, only you haven't previously written it:

Transfer.get() retrieves a specific Transfer object (which is defined in your Transfer XML) with a Primary Key ID of "1". Then it simply calls the generated "getFirstName()" method on that object and returns it to you. That's it! It is really simple.

This is hardly even skimming the surface of what Transfer does for you. Let's say that an employee can have multiple phone numbers on file that you store in a separate table called EmployeePhone. This is of course a One-to-Many relationship. Once you have simply defined this relationship in your Transfer XML you would then access the phone numbers this way:

From there you can simply loop through that array which in turn provides different EmployeePhone Transfer objects. You can configure in your XML whether that relationship will return an array or query. Notice that I mentioned it would return an array of Transfer Objects. This is where it gets tricky. The default return type of any relational object is typed as a Transfer Object. This is instantiated from the generic Transfer Object interface in the framework and is what all the relational object inherit from. However, you can change this by applying a decorator to any of your objects which will change the type of the object to the decorator path. The decorator will also allow you to add methods as well as change existing ones that the Transfer Object defines.

As you can see, Transfer can be very very powerful in your applications. It doesn't require very much setup time and configuration. As with most advanced concepts like this, it takes practice to really understand the underlying methodologies and to use them wisely in your application. Also, do not think that Transfer is simply a glorified code generator. Mark Mandel has spent a lot of time utilizing ColdFusion's unique strengths to truly make this a fast and effecient framework to keep your application at top speed.

That's it for now. Next time I will actually get more technical about the configuration file and start discussing how to prepare your CFC middle-tier for Flex consumption.

Related reading:

• Building an Application with Transfer ORM
• Transfer Google Group

Lately I have been using the Yahoo! Flex skin in a few of my interfaces as it greatly improves the overall standard look of the Flex widgets. It's very easy to implement (thanks to Adobe for creating a simple workflow for this). Recently, however, I have noticed a couple of bugs in the skin that are worth bringing up and should definitely be fixed. Suffice it to say that I am not sure if they are Adobe's fault or Yahoo!'s fault.

As you can see there is an issue on the bottom where a partial row of the datagrid is showing and the other part of it is hidden. It's the hidden part that is causing the skin to appear invisible. Note that, as soon as I scroll the datagrid it goes away. However, if I move my mouse over that row it comes back. Same goes for the [+] button. You can see that it's bounds are causing an anomaly on the control bar.

Like I said, I am not sure if this is an Adobe issue or a Yahoo! issue, but it is annoying enough that I might be swapping the skin out. I don't want to, but I may have to.