Love it or hate it describeType is the only (almost) way to preform reflection on types in actionscript, it returns a XML document containing information about a type in one big dump! There are a number of excellent and proven libraries out their that can convert that XML dump into a nice OO data structure for you to code against, and it crossed my mind several times while developing dawn that they could make my life a lot easier. I however, created another reflection library… what was I thinking!?

Thing is, I have never needed a full strongly typed objected orientated representation of my type! That would be nice of course, but when I turn to reflection its not to create Method and Parameter objects (I’d rather the runtime did that to be honest) its because there are specific things about a type that I need to find.

A simple example of what I need reflection for in dawn would be to find all the methods in a type that have been decorated with the [Inject] metadata and have one or more arguments. i.e. all the injectable methods for a Class. Whether the reflection API gives me a XML document or the same information parsed into types I’m still going to have develop a way of finding all the methods with Inject metadata. Maybe that will be with e4x or maybe a loop over some objects (perhaps ensuring that they are methods not variables/accessors), then I will need to check that those methods have some arguments and are thus injectable. So whatever the means the types reflection information is provided by, the actual logic of my task is entirely up to me to develop and test.

With all that in mind, I built Fussy to be a little different from current reflection libraries (at least those that I know of). I wanted something to help me query my types, where the query represented whatever I wanted to find out about my types. To show you what I mean by “query”, lets see how fussy allows me to find the injectable methods on a type (the problem from above)

Start by creating a fussy

var fussy:Fussy = new Fussy()

Now to describe my query

var query:IQuery = fussy.query().findMethods().withMetadata("Inject").withArguments();

Now I can execute that query against any type, and get a array of strongly types Method objects

var methods:Array = query.forType(MyClass);

And TA DA! I have strongly typed method objects that satisfy my query for MyClass.

So what is Fussy?

Seems quite late in this post to be asking that, but I figured it would be easier to explain after an example. I call fussy an actionscript reflection query language. It does of course perform reflection, and parse the result of that reflection into strongly typed objects (only after a query has run) but the main aim of fussy was to make the logic of reflection (the reason why I was reflecting in the first place) easier as faster.

Fussy is a work in progress, I still think I can make the query API more elegant and there are lots more query extensions I can think of to add but its already pretty useful. It now supplies dawn with all its reflection needs, and what was a huge proportion of dawns code (searching and parsing types) base has been reduced down to one class.

Got lots more plans for Fussy, including things like metadata schema validation.  I find its pretty useful, so figured someone else might too.

Oh, here is the github link

When I first demoed Dawns injector in a LBi tech talk (almost a year ago now) one clever chap asked how it could be used to create a number of very similar, but different objects graphs. I only half got my head around the question at the time, and blurted out something about named injections. Then sometime (and some beers) later after discussing the problem more it became clear that Dawn didn’t really have a very elegant solution to the problem.

Time to explain the problem (if you’ve heard of the robot leg problem, thats the one!). How can I create two similar object graphs, with some defined differences without having to create new concrete classes to represent those different graphs (thats what you would have todo today btw)? Example time.

Picture a Car class (or just read the one below)

class Car {

  var engine:Engine;
  var transmission:Transmission;
  var driveLine:IDriveLine;

  public function Car(engine:Engine, transmission:Transmission, driveLine:IDriveLine) {
    // set properties etc //
  }
}

Engine and Transmission are base classes that have a number of subclasses like PetrolEngine, DieselEngine, AutomaticTransmission and ManualTransmission. IDriveLine is an interface for the various type of drive the car could have, FrontWheel, RearWheel or FourWheel etc.

The Car class itself is pretty flexible (polymorphism is handy like that), depending on how we construct the car we could get a four wheel drive diesel or an manual transmission, rear wheel drive etc. In Dawn today you could create a configuration for your Car and install it into the injector.

class CarConfig implements IConfiguration {

  public function configure(mapper:IMapper):void {
    mapper.map(Engine).to(PetrolEngine);
    mapper.map(Transmission).to(ManualTransmission);
    mapper.map(IDriveLine).to(RearWheel);
  }
}

// then where you create your injector

injector.install(new CarConfig());

Using the above code, every time you requested for a Car from the injector it would create one with a petrol engine, rear wheel drive and manual transmission. *Every Time* is not what we want though! Without private configurations we would have to find a way round this, most likely by creating subclasses of Car, such as PetrolCar, which had a constructor parameter of type PetrolEngine, then the same for RearWheelDriveCar, and so on, until we had classes to represent the varieties of object graphs we wanted.

Private configurations are a port of Guices solution (private modules) to the same problem. They allow you to create groups of mappings that are only available under certain conditions.

Here are a couple of private configurations for the above problem

class SportyCarConfig implements IPrivateConfiguration {

  public function configure(mapper:IPrivateMapper):void {
    mapper.map(Engine).to(PetrolEngine);
    mapper.map(Transmission).to(ManualTransmission);
    mapper.map(IDriveLine).to(RearWheel);

    mapper.expose(Car, "Sporty");
  }
}

class ChelseaTractorConfig implements IPrivateConfiguration {

  public function configure(mapper:IPrivateMapper):void {
    mapper.map(Engine).to(DieselEngine);
    mapper.map(Transmission).to(AutomaticTransmission);
    mapper.map(IDriveLine).to(FourWheel);

    mapper.expose(Car, "4x4");
    mapper.expose(Showroom, "SUV Land");
  }
}

If the two configurations above were just normal configurations we would have a little problem when we installed then into the injector, since they both create mappings for the same types. So the second configuration to be installed would overwrite the first ones mappings for Engine etc. Also notice that both the private configurations make one or more calls to an *expose* method.

Installing private configurations is almost identically to installing normal ones:

var injector:IInjector = Injector.createInjector();

injector.installPrivate(new ChelseaTractorConfig());
injector.installPrivate(new SportyCarConfig());

Installed private configurations do not overwrite mappings within other normal configurations or private configurations. So when we install the SportyCarConfig we have not overwritten the settings in the ChelseaTractorConfig. But how then do we create a car that uses either one of those configurations? Well thats what the expose method is all about! Private configurations are private (hidden) until a special exposed mapping is requested from the injector. Once the exposed mapping is requested the mappings within the private configuration become public, and take precedence over any configurations that already exist in the injector.

Lets expand the above code snippet a little to add some default mappings for the IDriveLine, Engine and Transmission.

var injector:IInjector = Injector.createInjector();

// add default normal car mappings
injector.map(IDriveLine).to(FrontWheel);
injector.map(Engine).to(PetrolEngine);
injector.map(Transmission).to(ManualTransmission);

// install the private configurations
injector.installPrivate(new ChelseaTractorConfig());
injector.installPrivate(new SportyCarConfig());

Now if we request a Car from the injector (injector.inject(Car)) we will get the default options:

var car:Car = Car(injector.inject(Car));

trace(car.engine is PetrolEngine) // true
trace(car.driveLine is FrontWheel) // true
trace(car.transmission is ManualTransmission) // true

To activate a private configuration we must request one of the exposed mappings. Ok, lets create a sporty car.

var sportyCar:Car = Car(injector.inject(Car, "Sporty"));

trace(sportyCar.engine is PetrolEngine) // true
trace(sportyCar.driveLine is RearWheel) // true
trace(sportyCar.transmission is ManualTransmission) // true

This time when we asked the injector for a Car we specified the name of the mapping, Sporty. When the injector sees that we are requesting a mapping of type Car named Sporty, it activates the SportyCarConfig, since that is the *exposed* mapping of the configuration! It doesn’t matter that the configuration does not supply a mapping for those options (type Car, named Sporty), it just knows that thats the mapping that unlocks it.

Now we can create a four wheel drive car

var bigCar:Car = Car(injector.inject(Car, "4x4"));

trace(bigCar.engine is DieselEngine) // true
trace(bigCar.driveLine is FourWheel) // true
trace(bigCar.transmission is AutomaticTransmission) // true

This time we requested a mapping of type Car named 4×4, which is one of the exposed mappings that activates the ChelseaTractorConfig, so the car we get is provisioned with the mappings found in the ChelseaTractorConfig over the default ones.

And that in a nutshell is what private configurations are all about. They are a terse and clean way to separate configurations for object graphs which can be activated by special exposed mappings.

This is all tested and committed to the dev branch of Dawn awaiting inclusion in the next release

I am aiming for dawns injector to be a complete injection solution (shiny bells AND whistles!!). Its not doing bad, but there are a few places that some polish wouldn’t hurt (better error reporting is a big on one those, its on the way).

This latest change was born out of a request from Mr. Tink. He wanted to be able to map one class (in singleton scope) to two interfaces. While such an exciting feat was possible previously, it really required knowledge of factory providers (and consequently some custom code). The new solution is much neater and is as simple as pie… I hope, O.K. an example:

Lets say I have a model object that implements a simple interface for views (or mediators or whatever said framework fancies). Simple, except that I also want methods on the object that shouldn’t be exposed to the view objects, so those can be added to an interface that extends the original one with the extra functionality.

// for dumb clients things like views etc
interface IAccessData {
  function getMyThing():Thing;
}

// for services/commands etc
interface IChangeData extends IAccessData {
  function updateMyThing(wibble:Wibble):void;
}

class ThingModel implements IChangeData { ... }

ThingModel implements both of these interfaces, and I only want one of my models to be created and that same instance to be injected for anything that require either IChangeData or IAccessData.

Previously I would have either had to map to a factory or an instance twice to get this to work, i.e.

// pray it has no constructor dependencies
var myModel:ThingModel = new ThingModel();
injector.map(IAccessData).toInstance(myModel);
injector.map(IChangeData).toInstance(myModel);

or

injector.map(IAccessData).toFactory(ThingModelFactory);
injector.map(IChangeData).toFactory(ThingModelFactory);

class ThingModelFactory { ... blah ... }

Either way, I have to create two mappings and its not so fun. If there was a third interface, or I wanted to also map the concrete class to the same instance it would require a third mapping.

In the next version of dawn (already in the dev branch) we can just do this

injector.map(IAccessData).and(IChangeData).to(ThingModel).asSingleton();

Ta Da!!

Much easier. Under the hood dawn still creates two mappings, its just sugar coated with the mapping DSL and our lovely ‘and’

Its also “chainable” (is that a word? I doubt it).. so if I also wanted classes that depend on the concrete implementation of ThingModel to get the same instance,  I could just add another ‘and’

injector.map(IAccessData).and(IChangeData).and(ThingModel).to(ThingModel).asSingleton();

And there you have it, multi-mapping goodness.  There are lots of other things coming soon, I just needed to get that one off my chest.

Also worth checking out is the asEagerSinglton scope that just made it into 0.8

There are lots of good reasons for using commands in your applications. They are a proven solutuion for all sorts of common problems in client side development such as queueing, cacheing, batching etc. They are also very useful for performing business logic that spans multiple domains within an application, and thus belong in no one domain alone.

Why make another command library?

Enough of why commands are good (we all know that), why does Dawn contain its own flavour of this oh so common pattern? In turns out providing the command pattern is not a simple as it might seem in Actionscript, at least not if you have some design principles you intend to stick to. Most of the frameworks I have come accross in actionscript provide commands in a pretty similar way, the steps are somethings like this

1. Create a new object that implements some ICommand interface
2. implement the execute method, which takes some generic object as its argument. Find a way to get hold of any objects you need, perhaps a service locator (PureMVC) or a singleton (Caringorm)
3. define some string or event (a string type field) that triggers the command
4. configure the framework to trigger the command on the newly defined event (one-to-one mapping)

So what is wrong with that? How could that be better? It seems to me that those steps break a number of principles I think are fairly important, it also looks like a lot of work which could go wrong.

Take step 1. “Create a new object that implements some ICommand interface“. Everyone loves a bit of programming to interfaces! But there a snag here with Actionscript, that ICommand interface will have defined a type for its argument e.g.

interface ICommand{
    function execute(event:FrameworkEvent):void
}

In actionscript there is no way for me to extend an interface and narrow the type of the argument, this for example would be impossible

interface MyCommand extends ICommand{
    function execute(event:MyFrameworkEvent):void
}

What that means is that any commands I write that want to get information out of the event that triggered them are going to have to cast the argument! Type safety FAIL! I want to be able to write type safe commands that know the exact type of their arguments.

Step 2. “implement the execute method, which takes some generic object as its argument. Find a way to get hold of any objects you need, perhaps a service locator (PureMVC) or a singleton (Caringorm)” You can probably guess what I dont like about that. Commands are so valuable because they can encapsulate complex logic that involves a number of parts of an application. But commands are stateless (created each time they are executed) and tend to be created by the framework, so how can they get hold of the objects that they need to act upon? In most frameworks I have come across objects that need to be involved in commands either need to implement the singleton pattern – the enemy of testable code! Or register with a service locator, which adds new dependencies on the command to a service locator class and a random string against which the object may (fingers crossed) be registered against. I want my commands to have as few dependencies as possible, I dont want to have to rely on strings to get hold of the core actors in my system, and I certainly dont want to fall into the many traps thats singletons lay.

step 3. “define some string or event (a string type field) that triggers the command” Having created this command in framework X I now need to think about how to trigger its execution. I might have to create a new object that extends some base event to do this, or I may just have to choose a string name. I can just about deal with this step, I know that there is going to have to be something that triggers the command (I just dont think string or events are very good choices).

step 4. “configure the framework to trigger the command on the newly defined event (one-to-one mapping)” This is where the previous step starts to frustrate me. I have to TELL the framework that the object I just created is the one that will trigger the command. This will most likely look something like so

framework.registerCommand( MyThing.NAME, MyLovelyCommand );

There are a couple of things I don’t like about that, firstly it depends on developer discipline (I dont have that!), meaning it’s up to me to check that the value of MyThing.NAME is what it should be, the compiler won’t care if all my NAME properties have the same value!! Secondly it’s configuration, and configuration does not rock my boat.

how is Dawn different?

Heres an example of what a typical command might look like in Dawn (in a typical hay making application).

class MakeHayCommand{
   [Inject] public var barn:Barn;

   [Execute] public function execute( note:MakeHay ):void{
      barn.makeHay(note.howMuchHay);
   }
}

There are a few things to note

• there is no ICommand interface
• the argument to the execute method is specific to the business logic being executed
• the execute method has [Execute] metadata
• the barn variable has [Inject] metadata

You might have already guessed that a Dawn command was not going to implement an ICommand interface.  Dawn tries to make the most of Actionscript by using metadata over interfaces here inorder to preserve type safety. When this command is triggered the method that has the [Execute] metadata will be invoked (this also means that we could call the method anything we like, something more meaningful, like, makeTheHay).  Now that we have an argument that is specific to the business logic being executed we no longer need to perform risky runtime casting.

My other major gripe with commands is how core actors within a system are reached, Dawn makes this easy by building upon its dependency injection library.  Just like any other object in Dawn, the command need only specify what it needs by providing the [Inject] metadata.  Dawn will ensure that the relavent objects are constructed/retrieved before the command is executed, so all the logic to fetch domain objects via service locators or singletons is removed, making for a terser more testable command.

While all that type safety would be good on its own it also hands us another easy win with a bit of dry configuration.  We (and Dawn) can see the type of the argument of the execute method, so we can completely skip the configuration step (thats the nasty bit where we start defining strings all over the place), the command is implicitly mapped to the MakeHay notification.

Setting up and triggering a command then looks much simpler

We tell Dawn we have a new command (but skip any mapping step)

commands.addCommand(MayHayCommand);

Since the command system is built on top of Dawns other libraries (DI and notifications) we can just send a notification of type MakeHay to trigger the command.

notificationBus.trigger(new MakeHay(numberOfBales));

and we’re done.

One more quick win

Another nice feature we get for free by building on top of the notification system is that any command you write is mapped by type, and types can be concrete classes (like the above example) or abstract classes or even interfaces.

Here is a command that will log any notification that implements IResponder

class LogRpcCommand {
    [Execute] public function execute( responder:mx.rpc.IResponder ):void {
        trace("making rpc call", responder);
    }
}

Recap

Hopefully I’ve gone someway in justifying why Dawn implements it’s own command pattern.  I wanted to ensure my code stayed type safe, I didn’t want to invent verbose ways of getting hold of objects within the system, and I didn’t want to map classes to string.

I still have someway to go with them, there is more I want from them (queueing baked in etc) but I already find them very useful, and well worth their place in Dawn.

I also feel fortunate that I had such a good topic to talk on, as that always makes it easier so many thanks to Cliff for doing such a great job with PureMVC

In case anyone is interested I have uploaded the slides and the sample code…
code
slides (keynote)
slide (swf)

I particularly enjoyed the talk given by the BBC. The somewhat muted service they provide for non-Windows users has always been a bug bearer for me. I was pleased to hear though that they have been handed a solution to their licensing issues by the DRM support in Air 1.5. This means we can now have the same download manager facilities, along with some notification goodness, wrapped up in a shiny cross-platform AIR app – result.

Another demo that caught my eye was a news reader for the New York Times. I was shown the current New York Times news reader about a year ago. It’s a chunky WPF application, so no good to me in Unix land. What it did do very nicely however was display column based text in whatever sized window you might have the app open in. That same functionally is now available (or soon to be, I’m not sure if it’s out yet) in an Air application. This is no doubt made a lot easier by the new text rendering engine within Flash 10, which allows text to flow between containers. For some more info check out this report

Ohh, and for general information about the Keynotes go here

ta ta

ps, I’m also posting on the LBi blog, check it out here

The basic idea is that with a nominal amout of metadata Snooze can create your database, and perform CRUD operations for your objects.  It supports the most common relationship types, one-to-one, one-to-many, and many-to-many, and I am planning to build a querying api into it.

If your interested in finding out more about it you can check it out on github… where hopfully you will see a lot of commits from this lazy geek!

What you’ll need.

• BlazeDS
• Spring Framework (I’ve used 2.5)
• Flex 3.0 (I’ll be using Flex Builder, but you are free to just use the SDK)
• Eclipse with Spring IDE plugin
• blazeds-spring-beta1.jar

The Steps!

Creating The Java

1. Create a Spring project in eclipse named BlogExample and set the output folder to be war/WEB-INF/classes.
2. Find the directory you unzipped the BlazeDS download into and navigate to the following directory {blaze install dir}/tomcat/webapps/blazeds/
3. copy the contents of this directory into the new project (you should have copied two folders, called WEB-INF and META-INF. These folders contain the necessary libraries and config files for connecting to Java from Flex)
4. Copy spring.jar file from {Spring unzip directory}/dist/ into the war/WEB-INF/lib directory of the project. The project now contains all the necessary library’s to connect Flex to Java. However as we are using Spring we will still need one more jar file which we will get in step 9
5. Next you need to create your business logic, I have created a very simple POJO called SimpleBook.java, which contains two properties with getters and setters (you can download the complete project here which contains this simple class).
6. Create a new Spring Bean Definition File called beans.xml inside the WEB-INF directory.
7. Add the following lines to the new beans.xml file, it tells spring to instantiate SimpleBook and set its properties
   <bean id=”myBook” class=”uk.co.ziazoo.example.domain.SimpleBook”>
   <property name=”name” value=”my book” />
   </bean>
8. Next we need to edit the services-config.xml and remoting-config.xml so that flex can connect to the application. Your can download mine from here (remoting-config.xml, services-config.xml). Be sure to change the endpoint in the services-config.xml to point to your local tomcat server. I have used the tomcat that come with the BlazeDS download as it comes pre-configured to work with BlazeDS.
9. If you take a look within the services-config.xml you will see I am referencing a class named flex.messaging.factory.SpringFactory which doesn’t currently exist in the project. We can get this file thanks to http://www.igenko.org… here blazeds-spring-beta1.jar
10. Once you have downloaded the blaze-spring-beta1.jar just copy it into the war/WEB-INF/lib folder
11. Next its time to configure the web.xml file. The web.xml file that come with BlazeDS needs a little tweaking to get it to work with our spring app. Firstly the included file uses the older DTD based syntax, we need to change this to the newer XML scheme method. Once we have done that we need to change the <listener> property such that it fits the spring based development ideas. (The changes essentially allow Spring to instantiate the business classes, rather than letting Flex do it… this is crucial to the whole idea of Spring, and its called IoC, Inversion of Control). Once that changes are made the web.xml file should look like this web.xml
12. The Java code is now complete, all that remains is to deploy it to the tomcat server, I have done this using Ant, blogging how to setup Ant and starting tomcat are all fairly in depth and very dependent on the system they are being installed on, so I’ll keep quite on that. If you are stuck I recommend reading the build.properties and build.xml files in my project.

The Flex

I am using Flex Builder 3.0, so these steps will vary for other IDS etc

1. Create a new project and select the application type J2EE
2. Set the root folder to to the context root of the java app withing tomcat ie /Users/Sam/Documents/blazeds_b1_121307/tomcat/webapps/blogexample
3. Replace the contents of the main mxml file with the follow main.mxml
4. Run the flex app.. and you should see the following
   
   

And thats your lot!!!

OOPS… forgot to upload the full Java code… here ya go Java code

With the above in mind I though it was about time I created a little application that I could send around to plug my abilities etc, and you can see it here

A little about how it works

The app is built using Flex 3.0 and the Cairngorm framework. Data is pulled in via XML, and displayed using a simple image viewing component I created.

Why use Flex

Flex enables me to build the same breed of applications we have all been building with Flash for sometime… only with Flex we can do faster, more reliably, with a fuller api and using a decent IDE… whats not to like?

Why Cairngorm

Cairngorm is all about building complex RIA’s in a consistent MVC manner… adobe puts it like this “The Cairngorm microarchitecture is intended as a framework for Enterprise RIA developers”. As you may have noticed the little image viewer I’m using as my example code is no enterprise application, in fact it only has a couple of user gestures, I’m just trying to demonstrate my familiarity with the framework.

I think Cairngorm is very important to the Flex developer community, it offers a well proven methodology for building applications, which separates concerns, promotes testability and leads to very predictable, scalable solutions.

About the view

I wanted to build a little set of classes that would allow me to display items (which could be anything from products to images etc.) in a number of ways, and was simple to extend. The snappyviewer, which is the name of the component displaying the images is an implementation of those classes.

The main classes the view is built around are two interfaces IItemView and IItemDisplayer.

Both interfaces contain a function named display. The display function in IItemVIew is intended to delegate the displaying of items to the IItemDisplayer via composition. The display function in IItemDisplayer is implemented for various display types, ie, displaying items in a grid, or in a row (GridItemDisplayer & SlideItemDisplayer).

To change which type of view the IItemView uses I can set the IItemDisplayer though the dispayer setter function in IItemVIew and hey presto, the view is updated.

You can check out the code by right clicking on the application and selecting Source View.

Any feedback welcome

ps.. you can see the application here

Since I first heard about Flex over a year ago and started working with it I have been very impressed. It’s a great platform for developers to create amazing web applications on… but for me there has been one big elephant in the room, and that’s the designer developer workflow!

We’ve all seen Blend combined with XAML now, and if you’re anything like me the first thing you thought when you saw it was why on earth cant Adobe do that with mxml!!!! And now it looks like they have with the project codenamed Thermo.

Thermo allows designers to use the tools they love (like the mouse…) and to draw the application as that want it. Thermo will then convert, on the fly (or when imported from a program like photoshop) the graphics into mxml! Perfect! It even allows for visual tweaking of motions and transitions. Its looks the the application I have been dreaming the Flash IDE would become for ages!

I personally can’t wait to see what comes of this… my hope (and this may be pie in the sky right now) is that we can in the not too distant future say goodbye to the Flash IDE (well, us developers at least). This would enable developers to focus on building applications rather that bullying design into behaving like one!

For more info on thermo check out this demo.